If people generate N-1 commits with a final one to clean things up, maybe people should learn about git stash and making some WIP branches, then squashing commits themselves or better yet, keeping their own history clean, instead of submitting PRs full of crap.
I know, it might be too much to ask of people... oh well.
The Mikado method is sadly underemphasized.
Just because you smash away at code for hours doesn't mean that's how your commit history should look. You can revise history in ways that are beneficial instead of destructive.
What is the cost of just doing it at the last merge step? Makes it easier, doesn't it?
Yeah, but dreadful if you try to bisect a problem.
Re:Squash your commits
by rjayatilleka on Saturday April 02, 2016 @09:43AM
(#11411476)
Yeah, and that's why you squash all the intermediate commits first. If all your commits on master are useful and meaningful individually, bisect works great.
Re:Squash your commits
by forrestthewoods on Saturday April 02, 2016 @03:59AM
(#11410692)
> Neither the project nor the author benefit from having those intermediate commits integrated verbatim.
Sure they benefit. You can see the thought process that went into the commit. If there's something that seems weird or out of place you can see how it evolved into existence. That can be exceptionally useful.
Unfortunately, that's not the 90% case that I see. Most of the time a multi-commit PR contains N-1 commits of incremental development and one final one that fixes all the tests and typos and removes debugging print statements. Neither the project nor the author benefit from having those intermediate commits integrated verbatim.