Git: Please Stop Squash Merging

Git: Please Stop Squash Merging
lucasoshiro.github.io

> My experience has been the opposite. Every organization I worked at used Trunk based development (feature branch->master).

Each repository has its own necessities and you need to adapt the workflow to them. Sometimes for small repos what's work the best is commits on main, some people like the so-called "git flow", and Linux have different maintainers for each subsystem.

> Because branches are short lived and usually small, they are the atomic representation of a change, and not the commits in the pull request.

If they are small enough they can be a single commit. No problem in doing that, and the result will be similar to squashing. If they need more than one commit, so they are not exactly "small"

> Pull requests usually have lots of "linting", "fixing test", "fixing typo" commits that I absolutely do not want in my master branch.

I agree that if someone commits something and then commits a "lint", "fix typo", this could be solved in commit correctly once. But this is not always possible, so one can use the rewriting history tools that were mentioned.

But I return the question: what are the downsides of having those commits?

> Blanket statements like these are not productive.

What, exactly, was blank? I tried to justify everything that I could based on the how Git works and debunk statements like "squash makes the history cleaner" (which, in fact, are blank).

> just assumes that it's because people just don't understand how git works.

So, I make the same question of the text: after reading and knowing what squash merges really are, what are the good reasons to still use them?

I've worked in orgs that use long lived branches and short lived branches... And short lived branches are by far less stressful to deal with if you can do it, precisely because of merge conflicts.

Reality is never going to match your desire. Things are going to get messy, and so you end up with squashable commits among your commits that shouldn't be squashed. The branch you're merging should match your intent for atomic changes to the code that can be easily reasoned about when rebasing, merging, and bisecting.

You write to history once, but you read from it many times. Therefore, optimize for reads.

I've worked with quite a few organizations and many of them use squash merges. Commits are often made because of a failed lint check needs a new formatting commit, addressing some comments to tweak some minor details, or even basic documentation changes. The pull request on GitHub ends up being the source of truth for the change, not the git log, and squash merges do a great job at keeping a single pointer to the parent pull request. Ignoring these nuances and how git interacts with other tools amounts to telling the user they're holding it wrong.

Clearly, squash merging does something useful but the author is totally not interested and declares that squash merging is good for one exceptionally specific use case, the only true clean commit history is not using git at all, and the problem exists between the keyboard and the computer.

So what if git doesn't have a single command to 'squash-merge'? It doesn't natively support a 'pull request' workflow either. Code forges build convenience functionality on top of git. If I didn't have the 'squash merge' feature I'd just use an interactive rebase to fixup/squash the branch's commits before doing a fast-forward-only merge, because I don't want a git history littered with meaningless noise.

And the 'fewer commits are better so that must mean no commits is best' argument is such an obvious slippery slope fallacy, come on man. Do you seriously think this kind of argument will fly in real life? You are just going to annoy the crap out of everyone. We don't squash and rebase because we want fewer commits, we do it because we want fewer meaningless noise commits. Do you want to preserve all your editor keystrokes, like backspaces, moving code around, copy-pasting, etc., before committing? If you don't, then you obviously don't want to track any history, right? Of course not, that's silly. That's what your argument is like.

I don't want my repo history littered with meaningless noise like these merge commit messages:

    * Merge pull request #1234 from bob/implement-foo
    * Implement foo (pull request #1234)

I also don't want a commit history that looks like London's tube system map. Please, keep the history linear so that myself and future team members can quickly focus on the parts that interest them, after just a glance, and don't have to spend time decoding the tangled mess of interlocking branch histories. Much appreciated!