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

From: Johannes Sixt <j6t@kdbg.org>
Date: Nov 6, 2020, 23:13 UTC
Message-ID: <43de6950-a33c-f3da-2a76-72719fef5af3@kdbg.org>
In-Reply-To: <CABPp-BGAJiaU5aeC3sGvp3znQw1esrn9c19gyOZQBymYvNFCaw@mail.gmail.com>

Am 06.11.20 um 21:27 schrieb Elijah Newren:

Show 38 quoted lines

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

Show 12 quoted lines

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

Show 6 quoted lines

> 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