git squash-merge — for people who hate:

* Long-lived branches
* Change history
* Parallel/decoupled maintainence of application/features and CI pipelines.
* Nice things.

@maranomynet

You love your change history, you say? Do you love it enough not to litter it with `lint fix` and `fix typo` and `empty commit to retry failed CI job` commits from feature branches? If not, it's a lukewarm fondness. :-)

@gthb Yes.
Squash merges are good for exactly two things:

1. Writing abbreviated history
2. Preventing (sensitive?) metadata leaking.

There are other and better ways to be a neat freak about your git history, and if you want to want to prevent metadata escaping, you should be doing your squashed commits off in a separate repo anyway.

@gthb
On the other hand, squash merge strategies require the whole team to strictly abstain from large parts of git's basic feature set (and usage idioms) – lest you end up with repeated problems that are hard to decipher and to untagle.

Even veteran git users often have a hard time reasoning about how and why things went wrong and frequently end up force-resolving conflicts incorrectly and thereby losing valuable changes (and then the evidence of that gets wiped after the merge).