Further Thoughts on When Not To Squash

[0cjs]

I'm happy to see post blog/content/1311-git-squash.rst discussing when and when not to squash since I too don't think it should be an automatic decision. I'm a big fan of rewriting history on dev branches to make things more clear, merge 'insert bug' / 'fix bug' commit pairs, and so on.

But I think there's a more general rule for this that you don't mention: or split commits (before putting them on master) as necessary to make your commits easier to review. So, as examples:

1. When you have a commit that introduces a bug and a later commit that fixes the bug, squash the latter into the former.
2. When you are making whitespace changes, formatting changes or refactorings, keep these as separate commits. It's much easier to review (and ascertain correctness of) a refactoring commit followed by a functionality change than it is to do so when it's all squashed into one commit.
3. If your new functionality is large and can be nicely broken up into separate parts that are easier to review separately, make these separate commits, especially if some of your changes are only distantly related to other changes. (But each individual commit should pass all tests; don't propose a commit that doesn't work until its children are also added.)

I think of a set of commits I'm proposing for master branch as a story I'm telling to the other developers. Make the story as clear as possible, divided up into reasonably small chunks where you can do so. This will make other developers love, rather than hate, reviewing your code.

And when you're bringing code on to master from a PR, consider this. There's nothing more frustrating to me when I try to contribute to a project than to have a half dozen carefully crafted commits, each making a clear and distinct change, squashed into a giant ball of mud.