[stormbrew]

> This is why my team and I moved to squash merging. Sure it has it's own drawbacks, but they're far less worrisome than rebasing. If you screw up a rebase, the history is re-written or force-pushed by accident. If you screw up a squash merge, you can still check out the intermediate commits if you know the hash

Until the original branch is deleted and the refs are garbage collected, anyways.

It seems strange to me to advocate for squash merging on a premise of not losing history. A squash merge is a rebase.

[steveklabnik]

  > A squash merge is a rebase.

Well, it's not a rebase in the literal sense: the base commit isn't changing. It _is_ modifying history, though.

[stormbrew]

It probably is in the same sense that 'git rebase -i' often puts the new branch on a new base even if that wasn't your explicit intention. Usually merge squashes are reparented to the current head of the target branch.

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.

[steveklabnik]

Ah, sorry, I'm probably mis-understanding a "squash merge". I thought you meant you have a graph like this:

    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.

[tomstuart]

That’s right. `git merge --squash` doesn’t even make a commit, it just updates the working tree and index to look like the post-merge contents — it’s then up to you to actually commit. So yeah, you don’t even end up with a merge commit.

[steveklabnik]

Ah ha! TIL. Thank you!

(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.)

[stormbrew]

I'm sure someone out there does it like that (the joy and pain of git being there's a million ways of doing things), but the name I think is derived from the idea that you're replacing a merge commit with a squash of the disjoint parent, rather than a merge of a squash.

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.

[steveklabnik]

No, I think you're right; take a look at the graphs on https://github.com/blog/2141-squash-your-commits for example.

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.