[lloeki]

In 25 years of professional development I have several counter examples where some bit was either a trivial git revert of a single commit - among multiple ones in a branch - away, or an absolute pain because the squash-merge commit had flattened too many concerns together, concerns that were perfectly split in the topic branch but that branch was long gone by virtue of being auto-deleted on PR merge.

Coincidentally, every single squash-merge commit advocate I've had the unfortunate debate with was a regular practitioner of public tmp / tmp / try again / linter / tmp / fix / fix / haaaaaands commits.

Note that I'm not against squashing/history rewriting e.g rebase -i and stuff (which I'm a heavy user of so as to present sensible code aggregation reviewable per-commits), only squash-merge.

[homebrewer]

I take it you haven't had the pleasure of working with your average ("dark matter" as they're called here) developers. I wouldn't call myself an "advocate" of squashes, but it's often the only practical way of keeping git history somewhat usable when working with people who refuse to learn their VCS properly.

I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.

But: most of the people I've been interacting with also produce lots of "wip"/"tmp", but then skip the rebase. I can only offer my help with learning git rebase for so long before it starts taking too much time from the actual work. So squash it is: at least it produces coherent history without adding thousands of commits into `--ignore-revs-file`.

[skydhash]

And sometimes, a patch is just that big. especially in UI works where a single change can cascade down to multiple layers.

> I chunk my changes into tiny commits ("linter"/"tmp"/"wip"), but then rebase aggressively, turning it into a set of logical changes with well-formed commit messages. git bisect/revert work great with history written in this way even years layer.

In a PR based workflow, it has become easier to have the PR be a logical unit than to `rebase -i` all the time on my end.

[skydhash]

If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.

A ticket should be atomic describing a single change request. PR in this case are the working room. It can be as messy or as clean as you want. But the goal is to produce a patch that introduces one change. Because if you would rebase -i at the end, you would have a single commit too in the PR.

[ahartmetz]

No, you wouldn't. git rebase -i is to remove noise, which is about merging commits that, well, make more sense together than apart. Which is mostly about summarizing trivialities (e.g. several typo fixes) and squashing fixups into commits that introduced a problem in the same branch.

A typical bugfix branch might look like this after rebase -i:

Move property to a more appropriate place

Improve documentation of feature Foo

Fix accidental O(n^2) in feature Bar

Fix interaction of Foo with Bar

[locknitpicker]

> If you work with a ticket system, squash-merge gives you the same granularity, where a commit would refer to a single ticket.

With GitHub you can squash any PR merge. The link to the PR will include the complete history of the feature branch prior to the merge. Even the commit history prior to force pushes is tracked.