3 ms·

Squash merges are rebases.

by paulddraper 3y ago

recursive 3y ago
Just when I thought I was starting to understand git...
- Izkata 3y ago
  Rebase essentially means "create new commits out of old commits", the original use being to "move" a set of commits from one branch to another (think of the name as meaning, to change the base these commits started from). There's a few special cases that have their own names, a common one is when you amend a commit - to do that manually you'd make a new commit, then use interactive rebase to squash the two commits together into a new one (or, use the "fixup" command available in that tool, which is a squash that automatically picks the first commit message instead of asking for a new one). Squash merges will squash a whole branch into a single commit, rebasing it onto the target in the process, and then fast-forward the target to the new commit. It's a tightly controlled use of rebase, and can be thought of a bit like how "for", "foreach", and "while" loops are a tightly controlled use of "goto", an abstraction built on top of a far more flexible tool.
ksenzee 3y ago
Only metaphorically, maybe. You can squash merge in lots of cases where a rebase will fail.
- Izkata 3y ago
  They are essentially rebase+squash, despite the name. There is no actual merge taking place. And for that matter, you'd manually do a squash with the interactive rebase tool anyway ("git rebase -i").
  - ksenzee 3y ago
    Imagine a feature branch where someone has been keeping it up to date by merging main into it regularly. Now the feature is ready to go into main. You can easily `git merge --squash` that branch into main. You can likely do the same thing manually (as you point out) by running `git rebase -i` if you squash all the commits in the branch. But you’ll never manage to do a genuine rebase, where every commit in the branch gets turned into a clean non-merge commit onto main.
    - paulddraper 3y ago
      FWIW I consider `git rebase -i` to be a "genuine rebase"
      - ksenzee 3y ago
        I do too, except in cases where it’s being used simply as a more complicated UI for `git merge --squash` and there’s no actual “generate a diff and apply it to a different base commit” going on.
        paulddraper 3y ago
        I think we have a rose by any other name situation. I call that a rebase.
        Dylan16807 3y ago
        That's a badly fitting analogy because there's only one type of flower involved. In this situation, they're saying that most things you might do with "rebase -i" are rebases, except for one. I'll make a math analogy. Technically a rectangle is a trapezoid, but if someone says tries to draw a distinction between rectangles and proper trapezoids, it's not hard to figure out what they mean. When rebase -i outputs a single commit, that's a degenerate case. There are statements about rebases that are generally true but not true for that specific kind.

Squash merges are rebases.

recursive 3y ago

Just when I thought I was starting to understand git...

Izkata 3y ago
Rebase essentially means "create new commits out of old commits", the original use being to "move" a set of commits from one branch to another (think of the name as meaning, to change the base these commits started from). There's a few special cases that have their own names, a common one is when you amend a commit - to do that manually you'd make a new commit, then use interactive rebase to squash the two commits together into a new one (or, use the "fixup" command available in that tool, which is a squash that automatically picks the first commit message instead of asking for a new one). Squash merges will squash a whole branch into a single commit, rebasing it onto the target in the process, and then fast-forward the target to the new commit. It's a tightly controlled use of rebase, and can be thought of a bit like how "for", "foreach", and "while" loops are a tightly controlled use of "goto", an abstraction built on top of a far more flexible tool.

ksenzee 3y ago

Only metaphorically, maybe. You can squash merge in lots of cases where a rebase will fail.

Izkata 3y ago
They are essentially rebase+squash, despite the name. There is no actual merge taking place. And for that matter, you'd manually do a squash with the interactive rebase tool anyway ("git rebase -i").
- ksenzee 3y ago
  Imagine a feature branch where someone has been keeping it up to date by merging main into it regularly. Now the feature is ready to go into main. You can easily `git merge --squash` that branch into main. You can likely do the same thing manually (as you point out) by running `git rebase -i` if you squash all the commits in the branch. But you’ll never manage to do a genuine rebase, where every commit in the branch gets turned into a clean non-merge commit onto main.
  - paulddraper 3y ago
    FWIW I consider `git rebase -i` to be a "genuine rebase"
    - ksenzee 3y ago
      I do too, except in cases where it’s being used simply as a more complicated UI for `git merge --squash` and there’s no actual “generate a diff and apply it to a different base commit” going on.
      - paulddraper 3y ago
        I think we have a rose by any other name situation. I call that a rebase.
        Dylan16807 3y ago
        That's a badly fitting analogy because there's only one type of flower involved. In this situation, they're saying that most things you might do with "rebase -i" are rebases, except for one. I'll make a math analogy. Technically a rectangle is a trapezoid, but if someone says tries to draw a distinction between rectangles and proper trapezoids, it's not hard to figure out what they mean. When rebase -i outputs a single commit, that's a degenerate case. There are statements about rebases that are generally true but not true for that specific kind.