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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 06.11.20 um 21:27 schrieb Elijah Newren:
On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <kes-kes@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux