git rebase/git rebase --abort cause inconsistent state

git rebase/git rebase --abort cause inconsistent state

[Eugen Konkov]

Hi

I try to rebase, get conflicts. So I decide to --abort

After --abort I expect state before rebasing, but I get conflicts.

I  supposet  this  is  because `git rebase` switches to not branch and
--abort can not return to branch I was on before rebasing

Is this a bug?




kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
Created autostash: 566876c8
warning: Cannot merge binary files: share/ChangeAgreement.docx (HEAD vs. f2442d9a... Update Docs.pm)
Auto-merging share/ChangeAgreement.docx
CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
error: could not apply f2442d9a... Update Docs.pm
Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".
Could not apply f2442d9a... Update Docs.pm
kes@work ~/t/lib/MaitreD $ git rebase --abort 
Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.

Here is a tree before rebasing:
> a9597aaa (HEAD -> dev) Use DateTime with correct timezone
> 822ff801 Add link to Podio into mail
> 65575afe Update Docs.pm
| < e0003861 (local/dev) Update podio.t - test person contacts
| < 28ab8630 Create docdate if agreement is new and update test for that
| < 208ead68 Specified checking of person
| < f2442d9a Update Docs.pm
|/  
o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

Here is conflicts:
HEAD detached from 142c1b15
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
1       modified:   ../../Makefile
2       modified:   ../../etc/maitre_d.development.conf
3       modified:   Command/bank_statement.pm
4       modified:   Command/invoicing.pm
5       modified:   Command/reminding.pm
6       modified:   Controller/Cart.pm
7       modified:   Controller/Saldo.pm

Unmerged paths:
  (use "git restore --staged <file>..." to unstage)
  (use "git add <file>..." to mark resolution)
8       both modified:   Controller/Podio.pm

$ git --version
git version 2.28.0


-- 
Best regards,
Eugen Konkov

Re: git rebase/git rebase --abort cause inconsistent state

[Eugen Konkov]

Hello Eugen,

Friday, November 6, 2020, 8:32:13 PM, you wrote:

> Hi

> I try to rebase, get conflicts. So I decide to --abort

> After --abort I expect state before rebasing, but I get conflicts.

> I  supposet  this  is  because `git rebase` switches to not branch and
> --abort can not return to branch I was on before rebasing

> Is this a bug?




> kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
> Created autostash: 566876c8
> warning: Cannot merge binary files: share/ChangeAgreement.docx
> (HEAD vs. f2442d9a... Update Docs.pm)
> Auto-merging share/ChangeAgreement.docx
> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
> error: could not apply f2442d9a... Update Docs.pm
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm <conflicted_files>", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase --abort".
> Could not apply f2442d9a... Update Docs.pm
> kes@work ~/t/lib/MaitreD $ git rebase --abort 
> Applying autostash resulted in conflicts.
> Your changes are safe in the stash.
> You can run "git stash pop" or "git stash drop" at any time.

> Here is a tree before rebasing:
>> a9597aaa (HEAD -> dev) Use DateTime with correct timezone
>> 822ff801 Add link to Podio into mail
>> 65575afe Update Docs.pm
> | < e0003861 (local/dev) Update podio.t - test person contacts
> | < 28ab8630 Create docdate if agreement is new and update test for that
> | < 208ead68 Specified checking of person
> | < f2442d9a Update Docs.pm
> |/  
> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

> Here is conflicts:
> HEAD detached from 142c1b15
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
> 1       modified:   ../../Makefile
> 2       modified:   ../../etc/maitre_d.development.conf
> 3       modified:   Command/bank_statement.pm
> 4       modified:   Command/invoicing.pm
> 5       modified:   Command/reminding.pm
> 6       modified:   Controller/Cart.pm
> 7       modified:   Controller/Saldo.pm

> Unmerged paths:
>   (use "git restore --staged <file>..." to unstage)
>   (use "git add <file>..." to mark resolution)
> 8       both modified:   Controller/Podio.pm

> $ git --version
> git version 2.28.0


history after --abort:
* e0003861 (HEAD, local/dev) Update podio.t - test person contacts
* 28ab8630 Create docdate if agreement is new and update test for that
* 208ead68 Specified checking of person
* f2442d9a Update Docs.pm
* 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month


history before rebase:
a9597aaa (HEAD -> dev) Use DateTime with correct timezone



-- 
Best regards,
Eugen Konkov

Re: git rebase/git rebase --abort cause inconsistent state

[Elijah Newren]

On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <kes-kes@yandex.ru> wrote:
>
> Hi
>
> I try to rebase, get conflicts. So I decide to --abort
>
> After --abort I expect state before rebasing, but I get conflicts.
>
> I  suppose this  is  because `git rebase` switches to not branch and
> --abort can not return to branch I was on before rebasing
>
> Is this a bug?
>
>
>
>
> kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
> Created autostash: 566876c8
> warning: Cannot merge binary files: share/ChangeAgreement.docx (HEAD vs. f2442d9a... Update Docs.pm)
> Auto-merging share/ChangeAgreement.docx
> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
> error: could not apply f2442d9a... Update Docs.pm
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm <conflicted_files>", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase --abort".
> Could not apply f2442d9a... Update Docs.pm
> kes@work ~/t/lib/MaitreD $ git rebase --abort
> Applying autostash resulted in conflicts.
^^^^^^

Looks like you have rebase.autostash set to true and have some
uncommitted changes before your rebase started; it looks like it was
the reapplying of that stash at the time you abort is the thing that
failed.

According to the rebase docs for the --abort flag:
"If <branch> was provided when the rebase operation was started, then
HEAD will be reset to <branch>"
which suggests that the abort should switch you back to the original
branch, where the application of your local changes should be safe.
I'll cc the two most prolific committers to builtin/stash.c to get
their comments.

Some questions they may be interested in, though:  Is this bug
repeatable?  Can you find steps to reproduce and/or share your
repository?  Can you verify that you don't get this bug when
rebase.autostash is off?  What do your local changes before the rebase
look like and what are the nature of the conflicts afterwards (how
does a "git diff" before the rebase compare to a "git diff" after)?


> Your changes are safe in the stash.
> You can run "git stash pop" or "git stash drop" at any time.
>
> Here is a tree before rebasing:
> > a9597aaa (HEAD -> dev) Use DateTime with correct timezone
> > 822ff801 Add link to Podio into mail
> > 65575afe Update Docs.pm
> | < e0003861 (local/dev) Update podio.t - test person contacts
> | < 28ab8630 Create docdate if agreement is new and update test for that
> | < 208ead68 Specified checking of person
> | < f2442d9a Update Docs.pm
> |/
> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month
>
> Here is conflicts:
> HEAD detached from 142c1b15
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
> 1       modified:   ../../Makefile
> 2       modified:   ../../etc/maitre_d.development.conf
> 3       modified:   Command/bank_statement.pm
> 4       modified:   Command/invoicing.pm
> 5       modified:   Command/reminding.pm
> 6       modified:   Controller/Cart.pm
> 7       modified:   Controller/Saldo.pm
>
> Unmerged paths:
>   (use "git restore --staged <file>..." to unstage)
>   (use "git add <file>..." to mark resolution)
> 8       both modified:   Controller/Podio.pm
>
> $ git --version
> git version 2.28.0
>
>
> --
> Best regards,
> Eugen Konkov
>

Re: git rebase/git rebase --abort cause inconsistent state

[Johannes Sixt]

Am 06.11.20 um 21:27 schrieb Elijah Newren:
> On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <kes-kes@yandex.ru> wrote:
>> I try to rebase, get conflicts. So I decide to --abort
>>
>> After --abort I expect state before rebasing, but I get conflicts.
>>
>> I  suppose this  is  because `git rebase` switches to not branch and
>> --abort can not return to branch I was on before rebasing
>>
>> Is this a bug?
>>
>>
>>
>>
>> kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
>> Created autostash: 566876c8
>> warning: Cannot merge binary files: share/ChangeAgreement.docx (HEAD vs. f2442d9a... Update Docs.pm)
>> Auto-merging share/ChangeAgreement.docx
>> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
>> error: could not apply f2442d9a... Update Docs.pm
>> Resolve all conflicts manually, mark them as resolved with
>> "git add/rm <conflicted_files>", then run "git rebase --continue".
>> You can instead skip this commit: run "git rebase --skip".
>> To abort and get back to the state before "git rebase", run "git rebase --abort".
>> Could not apply f2442d9a... Update Docs.pm
>> kes@work ~/t/lib/MaitreD $ git rebase --abort
>> Applying autostash resulted in conflicts.
> ^^^^^^
> 
> Looks like you have rebase.autostash set to true and have some
> uncommitted changes before your rebase started; it looks like it was
> the reapplying of that stash at the time you abort is the thing that
> failed.
> 
> According to the rebase docs for the --abort flag:
> "If <branch> was provided when the rebase operation was started, then
> HEAD will be reset to <branch>"
> which suggests that the abort should switch you back to the original
> branch, where the application of your local changes should be safe.

Unfortunately, that is not always the case, for example, in this one.

>> Your changes are safe in the stash.
>> You can run "git stash pop" or "git stash drop" at any time.
>>
>> Here is a tree before rebasing:
>>> a9597aaa (HEAD -> dev) Use DateTime with correct timezone >>> 822ff801 Add link to Podio into mail
>>> 65575afe Update Docs.pm
>> | < e0003861 (local/dev) Update podio.t - test person contacts
>> | < 28ab8630 Create docdate if agreement is new and update test for that
>> | < 208ead68 Specified checking of person
>> | < f2442d9a Update Docs.pm
>> |/
>> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

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:

> history after --abort:
> * e0003861 (HEAD, local/dev) Update podio.t - test person contacts
> * 28ab8630 Create docdate if agreement is new and update test for that
> * 208ead68 Specified checking of person
> * f2442d9a Update Docs.pm
> * 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

and at this point, your stashed changes, which were snapshot when you 
were on branch dev, are obvously in conflict with branch local/dev.

I'm not saying that that the behavior should be like this, I'm just 
explaining what was going on. I hate this behavior, BTW.

-- Hannes

Re: git rebase/git rebase --abort cause inconsistent state

[Eugen Konkov]

Hello Johannes,

Saturday, November 7, 2020, 1:13:04 AM, you wrote:

> Am 06.11.20 um 21:27 schrieb Elijah Newren:
>> On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <kes-kes@yandex.ru> wrote:
>>> I try to rebase, get conflicts. So I decide to --abort
>>>
>>> After --abort I expect state before rebasing, but I get conflicts.
>>>
>>> I  suppose this  is  because `git rebase` switches to not branch and
>>> --abort can not return to branch I was on before rebasing
>>>
>>> Is this a bug?
>>>
>>>
>>>
>>>
>>> kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
>>> Created autostash: 566876c8
>>> warning: Cannot merge binary files: share/ChangeAgreement.docx (HEAD vs. f2442d9a... Update Docs.pm)
>>> Auto-merging share/ChangeAgreement.docx
>>> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
>>> error: could not apply f2442d9a... Update Docs.pm
>>> Resolve all conflicts manually, mark them as resolved with
>>> "git add/rm <conflicted_files>", then run "git rebase --continue".
>>> You can instead skip this commit: run "git rebase --skip".
>>> To abort and get back to the state before "git rebase", run "git rebase --abort".
>>> Could not apply f2442d9a... Update Docs.pm
>>> kes@work ~/t/lib/MaitreD $ git rebase --abort
>>> Applying autostash resulted in conflicts.
>> ^^^^^^
>> 
>> Looks like you have rebase.autostash set to true and have some
>> uncommitted changes before your rebase started; it looks like it was
>> the reapplying of that stash at the time you abort is the thing that
>> failed.
>> 
>> According to the rebase docs for the --abort flag:
>> "If <branch> was provided when the rebase operation was started, then
>> HEAD will be reset to <branch>"
>> which suggests that the abort should switch you back to the original
>> branch, where the application of your local changes should be safe.

> Unfortunately, that is not always the case, for example, in this one.

>>> Your changes are safe in the stash.
>>> You can run "git stash pop" or "git stash drop" at any time.
>>>
>>> Here is a tree before rebasing:
>>>> a9597aaa (HEAD -> dev) Use DateTime with correct timezone >>> 822ff801 Add link to Podio into mail
>>>> 65575afe Update Docs.pm
>>> | < e0003861 (local/dev) Update podio.t - test person contacts
>>> | < 28ab8630 Create docdate if agreement is new and update test for that
>>> | < 208ead68 Specified checking of person
>>> | < f2442d9a Update Docs.pm
>>> |/
>>> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

> 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


>> history after --abort:
>> * e0003861 (HEAD, local/dev) Update podio.t - test person contacts
>> * 28ab8630 Create docdate if agreement is new and update test for that
>> * 208ead68 Specified checking of person
>> * f2442d9a Update Docs.pm
>> * 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month

> and at this point, your stashed changes, which were snapshot when you 
> were on branch dev, are obvously in conflict with branch local/dev.

> I'm not saying that that the behavior should be like this, I'm just 
> explaining what was going on. I hate this behavior, BTW.
I also get inconsisten results https://stackoverflow.com/q/64592489/4632019
This depends on the remote history:
1)  when  there is changes to branch on remote server (sorry, it is named local
on pictures) and local changes to this branch
2)  when there is changes only to branch on remote server and no local
changes, so fast forward is possible


> Is this bug repeatable?
Yes

>Can you find steps to reproduce and/or share your repository?
do for commits.
push them to remote server
on  second  machine  fetch  this  branch  and  change the history. For
example the first made commit
push force back to server
fetch changes history from remote server on first machine
Then try to rebase remote history locally: git rebase dev local/dev
***local is name for local server, but this is remote history

This occur:
> and at this point, your stashed changes, which were snapshot when you
> were on branch dev, are obvously in conflict with branch local/dev.

Actually  here  I  this  of  `git  rebase  dev  local/dev`  as synonym
(probably incorrect) for `git pull --rebase`
Probably  here I am requred an option to drop those local commits that
were pushed to remote and which was changed on remote,
like this is done when `git pull --rebase`

I  prefer do `git fetch/git rebase` manually to keep thins in control.
`git pull` to my mind makes too many magic =(


>Can you verify that you don't get this bug when rebase.autostash is off?
This has no matter


>What do your local changes before the rebase
>look like and what are the nature of the conflicts afterwards (how
>does a "git diff" before the rebase compare to a "git diff" after)?
changes  was  at  binary  .docx  files.  Hope  I repeat upper those steps to
reproduce problem.


> -- Hannes



-- 
Best regards,
Eugen Konkov

Re: git rebase/git rebase --abort cause inconsistent state

[Junio C Hamano]

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.

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

Re: git rebase/git rebase --abort cause inconsistent state

[Eugen Konkov]

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

Hello Junio,

Monday, November 9, 2020, 8:11:46 PM, you 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.

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

Re: git rebase/git rebase --abort cause inconsistent state

[Johannes Schindelin]

Hi Junio,

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.

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

I agree with that, too.

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

Right. I think by now, the sanest way out of this fix is to do as you say,
stash only _after_ switching to the branch (if that was asked for).

Unfortunately, it is not that trivial to change `git rebase` to autostash
_after_ switching branches: we actually do skip the actual _checkout_
part, for performance reasons, as of 767a9c417eb (rebase -i: stop checking
out the tip of the branch to rebase, 2020-01-24).

My wishful thinking part wants Elijah's merge-ort work to be complete
already so that we can implement a purely in-memory, throw-away
cherry-pick of the autostashed changes on top of the branch to switch to,
and add that as a mandatory check _right after_ autostashing in `git
rebase`. I guess at some stage that will happen.

In the meantime, we might need to disallow `--autostash` with implicit
branch switching.

Ciao,
Dscho

Re: git rebase/git rebase --abort cause inconsistent state

[Johannes Sixt]

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