Junio C Hamano <gitster@xxxxxxxxx> writes: >> 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. -- 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