Re: [RFD] make rebase abort to original branch, not rebased branch

Junio C Hamano [off-list ref] writes:

quoted

Are there valid cases where the current behavior is bettter?

...
I don't particularly like the "when aborted it returns to the original
location" behaviour even for a single argument "git rebase A" case (I do
deeply care about the tip of the branch that you attempted to rebase _is_
set back to the original state, but I don't care deeply on which branch
you would end up on myself), but because "git rebase A B" is a shorthand
for "git checkout B; git rebase A" (at least that is how I view it
myself), I would imagine that it would be more surprising to switch back
to the branch you were on which may not have anything to do with A nor B.

At least going back to B conceptually makes more sense in one use case I
have, which was the original reason I invented rebase with the "checkout B
and rebase it ono A" shorthand in the first place (see 59e6b23), back when
I was an active contributor throwing patches at Linus (note that back then
I didn't have "abort then go back" in the code--and that is why I don't
care too deeply about this "which branch should I be after aborting?"
myself).
...

Having said all that, my opinion would be very different if the definition
of "git rebase A B" were different.  I can imagine that some people may be
tempted to (mis)understand the form of the command as a way to "rebase B
on top of A, even though I am doing something unrelated to B (my work may
or may not be related to A), because I need to help somebody who wants to
have an access to an updated B _now_, and I'll continue what I am doing
(which is not related to B) after I am done rebasing".

Actually, I would not say that such a workflow is unreasonable.

And for people who want such a workflow out of "rebase A B", it would be a
bug that the command does not to come back to your original branch when it
finishes rebasing B on top of A, and it would equally be a bug when it
stops with a conflict and you tell it to abort. In _both_ cases, you would
want to come back to the branch you started from.

But "git rebase A B" after successful completion does not come back to
your original branch (it stays on B), because the current semantics of the
command is not about supporting such a workflow.