squash merges vs non-squash merges

Various schools on how to merge development branches into master.

Github's web UI traditionally supported only regular merge on pull requests. Now has squash merge too.

Squash merge loses the history on the development branch, and replaces it with a single commit. Mainly I think the argument one was or the other is: do you want to see that history in the longer term? What is that history?

On most projects I've worked on, what lives on the development branch is a load of crap, with "whoops, try again" style commits.

with db migrations applied to live database, some kind of associativity(?) law would be nice to have on all commits on master: going to an arbitrary commit, running migrations, then going to an arbitrary future commit and running migrations, (x n times) and finally at the head of master running migrations. No matter which / how many arbitrary intermediate commits are chosen, the end database should end up the same. If people are messing with bugfixing migrations on dev branches and then merging that messing into the master history, that can break this invariant - because they probably didn't add fixup migrations but instead edited, because "they were on a dev branch".

"I'm on a dev branch" .. not if your dev branch history is merged to master, you aren't.

If you're doing a bunch of dev on a dev branch that touches a lot of things (rather than feature-specific dev branches) maybe you do want that history preserved. Or maybe you shouldn't be doing that. (telltale sign: branches called 'benc-dev' rather than 'benc-widget-impl-dev')

another invariant: each commit in history passed the test suite successfully. this fails with dev branches. useful for bisecting semi-automatically. I'd like this although I've never managed to have a project where this was required. (it can be expensive if you're making lots of commits, but a squash merge solves that)

importance of "working" history: kinda don't get the point of that until you have to actually do it and experience side-branch noise. before you treat history as a "don't care, it's got a different version id" thing

for each commit you're merging: would have have made this commit directly to master? are you "proud" of it?

if you make a commit and then bugfix it in another commit, then you present to me in the future two commits, one of which you know to be broken - you make that first commit harder for me to read becaues maybe i don't realise it is broken. maybe i puzzle over why it seems broken. anyway you have wasted my time. you could have presented me with one commit that was higher quality.

related: http://chris.beams.io/posts/git-commit/ about quality commit messages