What does it mean to git rebase a branch on top of incoming changes?
tl;dr A fundamental misunderstanding of the rebase operation.
I confused myself yesterday and I've not quite recovered. Rider's phraseology isn't helping me either, but maybe that's just me. When Rider offers to "Rebase the current branch on top of incoming changes, what does "on top" mean? I checked with two branches that were too similar to see the difference without making a change in one, and I am hesitant to make any changes anyway in case the rebase is different to branch and doesn't leave me with a nice, atomic "rebase commit" like a merge does.
I visualise commit "trails" as vertical lines starting with the first commit at the bottom. First I imagined the proposed rebase to be like a merge, with two parallel commit trails, both starting at bottom and being joined by a zip. But that's an actual merge not a rebase, my first mistake. The "on top" phrase made me think of the commit trails as horizontal lines, with the incoming changes being the top line, to be "zipped" onto the bottom line, my second mistake because that's still really a merge.
Now I think what Rider actually means by "on top" is like what I've read about rebase in some docs, where the local branch is a single vertical line starting at the bottom. Then the rebase will take incoming commits and place them in the same line as the local branch, at the bottom, pushing the newer local branch commits up to be on top of the incoming commits, thus remaking the base of the local branch, hence the term rebase.
But then the order of the commits in the local branch doesn't add up because some incoming ones would have originally been made after some local ones. To keep them in order git would have to insert incoming commits in the correct order between local commits, but isn't that just a merge?
I confused myself yesterday and I've not quite recovered. Rider's phraseology isn't helping me either, but maybe that's just me. When Rider offers to "Rebase the current branch on top of incoming changes, what does "on top" mean? I checked with two branches that were too similar to see the difference without making a change in one, and I am hesitant to make any changes anyway in case the rebase is different to branch and doesn't leave me with a nice, atomic "rebase commit" like a merge does.
I visualise commit "trails" as vertical lines starting with the first commit at the bottom. First I imagined the proposed rebase to be like a merge, with two parallel commit trails, both starting at bottom and being joined by a zip. But that's an actual merge not a rebase, my first mistake. The "on top" phrase made me think of the commit trails as horizontal lines, with the incoming changes being the top line, to be "zipped" onto the bottom line, my second mistake because that's still really a merge.
Now I think what Rider actually means by "on top" is like what I've read about rebase in some docs, where the local branch is a single vertical line starting at the bottom. Then the rebase will take incoming commits and place them in the same line as the local branch, at the bottom, pushing the newer local branch commits up to be on top of the incoming commits, thus remaking the base of the local branch, hence the term rebase.
But then the order of the commits in the local branch doesn't add up because some incoming ones would have originally been made after some local ones. To keep them in order git would have to insert incoming commits in the correct order between local commits, but isn't that just a merge?
