@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.

@maranomynet
> Squash merges are good for exactly two things:

They are good for a larger number of things. But first:

1. Writing abbreviated history

Conveying changes at a _useful_ granularity is of no small value: I first did A, then realized it was a brainfart and corrected it to B; I don't need to _hide_ my interim brainfart from posterity (indeed it's kept around in the PR if people care to look), but I do posterity a disservice by cluttering up its default view with that noise.

@gthb This is a false binary. Cleaning up history is important, and comes in multiple flavors/methods.

One of which could be squash the branch, *then* merge (as opposed to the current effective "squash rebase"). Lots of cool options are available.