Community
Participate
Working Groups
I always get a bit confused on rebase, as to which branch is playing on which. I realized today that I think the tooltip for rebase is wrong/backwards. - I did some experimental work in master without creating a branch. I committed to master to save the work, and then wanted to get that commit into a new branch. - created a new branch XXXX (At this point I could have cherry picked the commit, but I wanted to play with rebase because I've been confused and wanted to see if there is a bug). In this scenario, *master* is the source branch (it has the commits I want) and *XXXX* is the target branch. The tooltip for rebase says... "Rewind commits from the active branch and replay them on top of the selected branch" Reading the tooltip, this tells me that the active branch is the source, and the selected branch is the target. So I should make *master* the active branch and then select "Rebase" from the menu next to *XXXX*, so that changes from master are played onto XXXX. This doesn't work. I get the message "UP TO DATE" and of course the commit I want is not there. Instead I had to make *XXXX* my active branch and choose "Rebase" from the menu at *master*. This achieved what I wanted, getting the commit in the new branch, but is not what the tooltip tells me to do. In addition, why do we use the word rewind at all? It implies to me that the index of the source branch would be affected, when in fact it is not, it is just "forward porting" the commits from the source branch to the target branch. So I think the tooltip for the current behavior would more accurately be: "Play the new commits on this branch into the active branch"
Rebase is inherently confusing, but the tooltip is technically correct. What rebase does is "rewind" any changes made in your branch since the point you diverged. It then effectively restarts the branch at the current HEAD, and then "replay" your commits on this newly rebased branch. The "replay" language here means that the commits are being rewritten (because their parent pointer has changed). You end up with entirely new commit hashes for any replayed commits. So it's definitely *not* the case that the commits from master are being replayed onto your topic branch. Now just because the tooltip is correct doesn't mean it isn't confusing and can't be improved! The way I think of it is more like, "Reset the branch point of the active branch to the current HEAD of this branch." Or, "Start my branch over again based on the latest state of master". It would also help if there was a hyperlink that says, "Huh?!?" or "Help!" that takes you to this very nice explanation: http://book.git-scm.com/4_rebasing.html I should mention your case isn't a good candidate for doing a rebase since your branches hadn't actually diverged. The use case is I made a bunch of commits in my topic branch, and then I want to incorporate changes made on master after the branch point. The end result is identical to a merge expect all the commit metadata from the changes in master are preserved intact (instead your topic branch commits are re-parented).
(In reply to comment #1) > was a hyperlink that says, "Huh?!?" or "Help!" that takes you to this very nice > explanation: > > http://book.git-scm.com/4_rebasing.html Susan, do our tooltips support links? We could improve the wording as John suggested and just place the link at the end.
yeah, I know this is atypical use case (in fact, it's the reverse from the typical rebase use case). I am still not in the habit of creating a topic branch right away. Sometimes I'm just messing around/experimenting and then I realize that what I have needs to be tucked away in a topic branch. So the explanation for why the original operation did nothing: - master had the more recent changes, but there was no divergence in the other branch, so there was nothing to do. Maybe part of reducing confusion is having a better message ("No divergent changes to rebase") rather than the standard UP_TO_DATE And the reason the reverse operation achieved what I wanted in this use case: -the topic branch was behind master, so there was nothing to rewind, but the rebase action caused it to fast forward to the changes in master, which was what I wanted.
(In reply to comment #2) > (In reply to comment #1) > > was a hyperlink that says, "Huh?!?" or "Help!" that takes you to this very nice > > explanation: > > > > http://book.git-scm.com/4_rebasing.html > > Susan, do our tooltips support links? We could improve the wording as John > suggested and just place the link at the end. we use a mix of browser hover and dojo tooltip. The first one, no, the second one, not sure. I had that very chapter open in my browser, and read it while opening this bug so having a link to it would not have helped my confusion at all. The fact that there was no divergence in my case made it more confusing, and there's something about having to parse "active" and "selected" in the tooltip (ok, the bold one is active, this one by my mouse is selected). When I was writing this bug, I was thinking it would be more helpful for the tooltips to be able to be filled in on the fly so that the actual branch names could be used. But really the main point, I think, is that my use case was weird, but there was no message anywhere that helped explain this. Something like "There are no commits to rebase" would have been more helpful than a link to a manual.
Updating the tooltip with the actual branch names would be handy in a number of cases. "active" vs "selected" is bound to be a subtle distinction that some people miss, and mistakes here can be expensive for the user.
(In reply to comment #5) > Updating the tooltip with the actual branch names would be handy in a number of > cases. "active" vs "selected" is bound to be a subtle distinction that some > people miss, and mistakes here can be expensive for the user. Another confusion is that the gesture seems backward. Normally when you select something and choose a menu command, that thing you selected is the one that gets manipulated. Here, I select a branch, click on an action, and some other branch (my active one) is the one that gets modified.
(In reply to comment #6) > Another confusion is that the gesture seems backward. Normally when you select > something and choose a menu command, that thing you selected is the one that > gets manipulated. Here, I select a branch, click on an action, and some other > branch (my active one) is the one that gets modified. Merge and Rebase work in a similar way in EGit. When you choose a branch and click Merge, the branch will be merged into the active branch. Of course you also have Merge available for the active branch. Using it will open a dialog where you could select a branch to merge. The first way just saves an extra step, you do the operation with one click. I think the current way is good, we just need to improve the tooltip. And of course we could add this second way with dialogs and selecting a branch to merge.
I'm changing the tooltip to "Start the active branch over again based on the latest state of the selected branch".
Fixed with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=a9e7b20840d552998e4312a506d2d0dbef1c1f7f The final version is: "Remove your commits from the active branch, start the active branch again based on the latest state of [branch name] and apply each commit again to the updated active branch." and [branch name] is the name of the selected branch to avoid confusion.
