Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> writes: > git rebase --onto mybranch START_SHA END_SHA > > In the middle, I decide to run 'git rebase --abort'. > > Just as the documentation states, it performs a checkout of END_SHA as > the restored branch. END_SHA has nothing to do with the originating > branch, and confusion ensues. > > Is there a reason why 'git rebase' should not store off the > originating branch and use that for an --abort, instead of <branch> > which is END_SHA? When END_SHA is an actual branch name (which by the way is almost always how I use --onto in my attempts to transplant my topics), and when I found out that the conflicts I see while rebasing the topic to a different starting point (i.e. --onto) is too much to handle for too little gain, I would not appreciate if --abort took me to the --onto branch, which is totally uninteresting for the purpose of what I was attempting to do, namely, to deal with the topic. If the command took me back to the tip of the topic that I failed to rebase, I can continue attempting to whip it in shape using different strategies from there (e.g. merging an older part of upstream into the topic before merging the topic back to the upstream). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html