4 ms·
They're not full of little lies. Projects insist on squash-before-merge to help developers keep their sanity. Imagine working on a fast-changing block of code
by zenlikethat 11y ago
They're not full of little lies. Projects insist on squash-before-merge to help developers keep their sanity.
Imagine working on a fast-changing block of code with 20 or so other people concurrently. If all 20 of those peoples have patches submitted to master for review, and all of those patches have multiple commits each, then every time one gets merged, the others will have to rebase to its changes and fix conflicts for _every single commit_ while the fast forward plays out. It's a horrible experience. It prevents desirable code from getting in as contributors drop out due to the browbeating.
Squashing commits can be the difference between tediously fixing something once vs. tediously fixing it 20 times. No one needs to know that you changed your mind about calling that struct "ConfigOpts" before it was ever introduced upstream.
- WorldMaker 11y ago«the others will have to rebase to its changes and fix conflicts for _every single commit_ while the fast forward plays out» I'm mostly sort of advocating a "rebase none of the things" approach. Fix conflicts only when they happen in a branch (the GitHub PR system very nicely doesn't let you merge branches that conflict with your target branch and with CI information even better it won't let you merge branches that don't build). It's really not a bad experience.