But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.
But my point was just that a merge squash is just a specific incantation of the git-rebase tool. And it is one of the most history destroying incantations, rather than the least.
C -> D -> E
/
A -> B
then you "squash merge" S------
/ \
A -> B -> F
where S is C + D + E.Whereas a rebase + (now fast-forward) merge would be
A -> B -> C' -> D' -> E'
and, if squashed during rebase -i or by some other means A -> B -> S
It seems you're saying a "squash merge" is the last one, I thought it was the second one.Also it's entirely possible I'm wrong, I'm a fan of merge bubbles (sometimes rebased for clarity), and avoid large squashes in general, so maybe I just don't understand how people do it. I don't know why you'd bother to keep both a merge and squash commit around, though.
I don't know why you'd want to do it that way either! But I also don't understand why you'd want to "never rebase", so when it comes to git, I assume that someone has reasons for doing all kinds of things I don't understand.
(One thing I really love about git is that it's a tool I use extremely often (it's something like, 20% of the commands I run in my terminal), yet I learn something new and useful all the time.)