Re:Git: Please Stop Squash Merging
by lucasoshiro on Monday July 01, 2024 @12:50PM
(#40847640)
> London's tube system map
Perhaps you live in London, a city with many subway lines and stations that makes many places easy to reach, just like a repository with commits that makes it easy to find where something was introduced.
I live in São Paulo, a city 2 times bigger than London but with a smaller subway map. Few places have a subway station near them. Finding the nearest station is only part of the problem, as we need to find a way to go from the station to where we need to be. Just like a repository that uses squash merges.
i don't care how you do it. squashing? git reset followed by sensible commits? intense ninja-like git commit hygiene? or my favorite, liberal amounts of git rebase -i?
the only things i care about are these:
1. your PR contains a series of atomic commits
2. each commit makes a single logical change.
3. that each logical change is adequately described by the corresponding commit comment
4. extra credit if the series of changes is consistent to build and work at each step
i don't want to see "ONE" commit per-feature unless it's trivial.
i do want to see the development process, but in a "publish"-able form
i don't want to see "WIP", "almost working", "fixed broken", "redesigned ...", etc. sausage being made. i especially DON'T want to see patches to files be changed and reverted multiple times as mistakes are made and fixed.
the final PR should be you publishing a nice finished series of patches to accomplish a new feature.
then! we simply rebase that nice simple series on top of master and merge it with an optional merge commit. this gets you a nice linear history while avoiding the information loss with simply squashing everything in a PR/feature into a single commit.