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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 13, 2011, 07:46 UTC
Message-ID: <7v8vwjihsu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vmxkzijpt.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 19 quoted lines

>> 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.