3 ms·
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 easil
by 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 agoFWIW I consider `git rebase -i` to be a "genuine rebase"
- ksenzee 3y agoI 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 agoI think we have a rose by any other name situation. I call that a rebase.
- Dylan16807 3y agoThat'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.