Már Örlygsson :nerd:git squash-merge — for people who hate:
* Long-lived branches
* Change history
* Parallel/decoupled maintainence of application/features and CI pipelines.
* Nice things.
Gunnlaugur Þór BriemYou 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).
@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.
Yes. If your beef is with “only ever squash-merge, or else!”, then I'm totally with you. The policy should be “leave useful history” and that can be case-dependent.
But “git squash-merge — for people who hate: [...] Change history [...] Nice things” did not seem to mean that.
Not sure what the false binary was. I was agreeing with you that squash-merges are good for writing abbreviated history, and just adding “yes, and let's not underestimate the value of that!”