Am 10.11.20 um 23:28 schrieb Johannes Schindelin:
On Mon, 9 Nov 2020, Junio C Hamano wrote:
Eugen Konkov <kes-kes@xxxxxxxxx> writes:
You start at branch dev. Then you use the two argument form
git rebase dev local/dev
and when you later
git rebase --abort
then you are not warped back to dev, but to local/dev:
I suppose `git rebase --abort` should return me back to `dev`, because
this is the state I was before the command. hmm... suppose it will not
return to original branch when [branch] parameter is specified for git
rebase
Yes, "git rebase [--onto C] A B" has always been a short-hand for
git checkout B
git rebase [--onto C] A
which means that if the second rebase step aborts, rebase wants to
go back to the state before the rebase started, i.e. immediately
after "checkout B" was done.
I think the root cause of the problem is that addition of the
"--autostash" feature (which came much later than the two-arg form)
was designed poorly. If it wanted to keep the "two-arg form is a
mere short-hand for checkout followed by rebase" semantics to avoid
confusing existing users (which is probably a good thing and that
seems to be what the code does), then the auto-stash should have
been added _after_ we switch to the branch we rebase, i.e. B. That
way, the stash would be applicable if the rebase gets aborted and
goes back to the original B, where the stash was taken from.
That makes a ton of sense to me.
Not to me. In particular, I would prefer to move away from the mental
model "two-arg form is shorthand for checkout followed by rebase".
First of all, it does not match the mental model of inexperienced users.
You have to have been deep in Git operations long enough to know that
the two-arg form is implemented by an initial checkout so that the
rebase can proceed as if it were the usual one-arg form.
Second, this initial checkout in two-arg form is not necessary at all to
begin the rebase. As a first step, the commits to be rebased must be
determined. For this, the traditional way is to ask for the range
BASE..HEAD (and in order not to change this query for two-arg form, the
checkout was added). But the commits can be determined with
BASE..${second_arg:-HEAD} without requiring a checkout. Then the first
unavoidable checkout is the one that goes to ONTO (with some further
shortcuts in an interactive rebase).
I really don't give a dime for the initial checkout. After a botched
two-arg rebase, I usually prefer that --abort brings me back to the
branch were I was when I started, and not to the branch that was the
second arg of the rebase.
In any case, the ship has long sailed, so ...
Well, then order it back. rebase is porcelain, not plumbing.
-- Hannes
