4 ms·
Absolutely. If someone formulates their PR such that every commit in the chain is small, easily reviewable, and passes all tests, that's fantastic! That makes r
by phasmantistes 11y ago
Absolutely. If someone formulates their PR such that every commit in the chain is small, easily reviewable, and passes all tests, that's fantastic! That makes reviewing code, searching history, and bisecting all easier.
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.
- jarfil 11y agoIf 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.
- hinkley 11y agoThe 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.
- cortesoft 11y agoWhat is the cost of just doing it at the last merge step? Makes it easier, doesn't it?
- chris_wot 11y agoYeah, but dreadful if you try to bisect a problem.
- rjayatilleka 11y agoYeah, 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.
- forrestthewoods 11y ago> 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.