mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Eugen Konkov <>
To: Junio C Hamano <>
Cc: Johannes Sixt <>, Elijah Newren <>,
	Git Mailing List <>,
	Thomas Gummerer <>,
	Johannes Schindelin <>
Subject: Re: git rebase/git rebase --abort cause inconsistent state
Date: Tue, 10 Nov 2020 19:59:52 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

Hello Junio,

Monday, November 9, 2020, 8:11:46 PM, you wrote:

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

> Of course, that would also mean that the original modification in
> the working tree and the index may not allow you to move to branch B
> (i.e. starting from your original branch O, and editing files in the
> working tree, "git checkout B" may notice that you edited files that
> are different between O and B and refuse to check out branch B to
> prevent you from losing your local modifications), but that probably
> is a good thing, if "two-arg form is a mere short-hand" paradigm is
> to be kept.  So, "use autostash and you can always rebase in a clean
> state" would no longer hold.

> Another thing we could have done when adding "--autostash", was to
> redefine the meaning of the two-arg form.  Then it starts to make
> sense to take a stash _before_ switching to the branch to be rebased
> (i.e.  B), to go back to the original branch before switching to B,
> and then to unstash on the working tree of the original branch that
> is checked out after aborting.

> Note that such an alternative design would have had its own issues.
> With such a different semantics of two-arg form, if a rebase cleanly
> finishes, instead of staying on the rebased branch B, we MUST go
> back to the original branch to unstash what was autostashed.
> Usually people expect after a rebase to play with the rebased state
> (e.g. test build), so staying on branch B that was just rebased
> would be far more usable than going back to unrelated original
> branch (and possibly unstashing).

> In any case, the ship has long sailed, so ...

I should try that usecases to have an opinion on that.

Currently I just add picture when `dev` is moved while rebasing.
This does not occur when `local/dev` does not point to `dev`
(when `local/dev/` and `dev` point different commits)

Also I will try --onto and how it suits to my work flow.

Best regards,
Eugen Konkov

[-- Attachment #2: _3.jpg --]
[-- Type: image/jpeg, Size: 94656 bytes --]

  reply	other threads:[~2020-11-10 18:00 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 [this message]
2020-11-10 22:28         ` Johannes Schindelin
2020-11-11  7:10           ` Johannes Sixt

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:

  List information:

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

  git send-email \ \ \ \ \ \ \ \ \

* 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

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