[lytefm]

Agreed. And I very much disagree with this paragraph:

> When a developer can go back to the individual check-ins leading up to the current code, they can work out the answers to such questions using only the level of personal brilliance necessary to be a good developer.

When I have to investigate past commits, I hate it to have to dig through a history of WIP commits containing code that didn't make it into the final version.

Of course it's also difficult to dig through a single commit with hundreds or thousands changed lines of code. But when a single commit includes a proper description and an issue reference, it much easier to investigate the developer's full intention than from multiple WIPs.

[chousuke]

Realistically, a single commit is not going to contain hundreds of thousands of lines of changes unless they're generated code or something.

I'm not advocating that you should merge branches by squashing all commits into one lump; that's definitely wrong. I think in terms of patch series, where each patch is a single commit that does something, and each feature is a series of patches consisting of stand-alone refactorings, bug fixes and new APIs required to implement the final feature.

But how I actually end up with that clean set of 1-n final commits in a PR or mailing list submission is no-one's business but mine.