git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Junio C Hamano <gitster@pobox.com>
Cc: Eugen Konkov <kes-kes@yandex.ru>,
	Elijah Newren <newren@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Thomas Gummerer <t.gummerer@gmail.com>
Subject: Re: git rebase/git rebase --abort cause inconsistent state
Date: Wed, 11 Nov 2020 08:10:53 +0100	[thread overview]
Message-ID: <ea62f9b7-483b-9187-25ee-b6116a25b757@kdbg.org> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2011102312020.18437@tvgsbejvaqbjf.bet>

Am 10.11.20 um 23:28 schrieb Johannes Schindelin:
> On Mon, 9 Nov 2020, Junio C Hamano wrote:
>> Eugen Konkov <kes-kes@yandex.ru> 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

      reply	other threads:[~2020-11-11  7:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06 18:32 git rebase/git rebase --abort cause inconsistent state Eugen Konkov
2020-11-06 18:34 ` Eugen Konkov
2020-11-06 20:27 ` Elijah Newren
2020-11-06 23:13   ` Johannes Sixt
2020-11-09 11:46     ` Eugen Konkov
2020-11-09 18:11       ` Junio C Hamano
2020-11-10 17:59         ` Eugen Konkov
2020-11-10 22:28         ` Johannes Schindelin
2020-11-11  7:10           ` Johannes Sixt [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea62f9b7-483b-9187-25ee-b6116a25b757@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kes-kes@yandex.ru \
    --cc=newren@gmail.com \
    --cc=t.gummerer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).