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

[Eugen Konkov <kes-kes@yandex.ru>]

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