> Squash merge has the major disadvantage of getting rid of valuable meaningful git history.
There are reasons against it but the real world is messy. Developers tend to commit things, recommit, undo, redo, move things around. Is this valuable history? It can be but I would say 99% of the time it's more valuable to have a good commit message about what was intended rather than what actually happened.
The idea of squash merge is to make the history clean from the get-go as you said.
> Developers tend to commit things, recommit, undo, redo, move things around.
I see 2-3 distinct final commits in that list there, ones that should be separate and not squashed into one:
* commit, recommit, undo (squash these ones, and depending on how much "undo" does could eliminate this entirely)
* redo (what exactly is in this one depends on how much "undo" did in the prior, and how the "redo" was done)
* move things around (feature is seemingly already working and this is a distinct separate "improve the code" step)
> Is this valuable history?
Keeping that last one separate is absurdly valuable when trying to figure out why the code acts the way it does, when a bug is reported later. A lot of bugs I encounter were in those steps when someone makes a simple typo moving the code around, and having it in the history makes it obvious it wasn't an intended change.
There are reasons against it but the real world is messy. Developers tend to commit things, recommit, undo, redo, move things around. Is this valuable history? It can be but I would say 99% of the time it's more valuable to have a good commit message about what was intended rather than what actually happened.
The idea of squash merge is to make the history clean from the get-go as you said.