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.

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.

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

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.

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.