Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase

[Phillip Wood <phillip.wood123@gmail.com>]

Hi Thomas

On 03/06/2020 17:09, Thomas Braun wrote:
> On 30.05.2020 18:24, Elijah Newren wrote:
>> On Sat, May 30, 2020 at 3:52 AM Md Naeim <naeim249@gmail.com> wrote:
> 
> [...]
> 
>> Could you provide any details beyond the subject, such as the output
>> from 'git rebase --abort', your git version, the output of `git
>> status`, whether there are any untracked files with special status
>> (e.g. ignored but a submodule in the way of something?), any special
>> file permissions (does root own some files and prevent git from
>> updating things?), operating system you are on, link to a repository
>> people can use to reproduce?  Without more details, this report is
>> unactionable.
>>
> 
> I don't know the OPs details but I can reproduce with the following
> clumsy snippet:

Thanks for the script, I've annotated the error messages in an attempt
to understand what's happening

> #!/bin/sh
> 
> git init
> git config --global user.email "you@example.com"
> git config --global user.name "Your Name"
> git config rebase.autostash true
> git config core.autocrlf false
> echo "*.abcd !eol" > .gitattributes
> git add .gitattributes
> git commit -m "Add attributes"
> echo -e "1\r\n" > test.abcd
> git add test.abcd
> git commit --no-verify -m "Added test.abcd" test.abcd
> echo "*.abcd eol=lf" > .gitattributes
> git add .gitattributes
> git commit -m "Add attributes (LF)"
> git rebase --root --interactive
> git rebase --abort
> which gives
> 
>  ./run.sh
> Initialized empty Git repository in E:/projekte/test-init/.git/
> [master (root-commit) 7169943] Add attributes
>  1 file changed, 1 insertion(+)
>  create mode 100644 .gitattributes
> [master 61f0599] Added test.abcd
>  1 file changed, 2 insertions(+)
>  create mode 100644 test.abcd
> [master 0acd46a] Add attributes (LF)
>  1 file changed, 1 insertion(+), 1 deletion(-)
> warning: CRLF will be replaced by LF in test.abcd.
> The file will have its original line endings in your working directory
> Created autostash: 310f745
> error: cannot rebase: You have unstaged changes.

The stash fails to stash all the changes because of some line ending
issue I've yet to understand but the stash command exit code is zero as
if it had succeeded in stashing everything so the rebase creates
.git/rebase-merge/autostash and continues

> error: Please commit or stash them.

only for the clean worktree check to fail. The cleanup path from that
point assumes we have not yet created .git/rebase-merge which is not
true if an autostash has been created. This means we do not pop the stash.

> error: could not read '.git/rebase-merge/head-name': No such file or
> directory

When we try to abort we try to read some state that does not exist
because the rebase never really started

> and
> 
> $ ls -la .git/rebase-merge/
> total 5
> drwxr-xr-x 1 thomas 197121  0 Jun  3 17:57 ./
> drwxr-xr-x 1 thomas 197121  0 Jun  3 17:57 ../
> -rw-r--r-- 1 thomas 197121 41 Jun  3 17:57 autostash
> 
> I'm running on Windows, both 2.27.0.windows.1 and 2.26.2.windows.1 show
> the problem. And I'm pretty sure it is not Windows specific.

You're right I can reproduce it on linux

> Although my test case uses EOL normalization, I think the real issue is
> that autostashing for the rebase fails (in the sense that the working
> tree is clean afterwards) and that is unexpected.

Yes. I'm not sure what to do for the best. A simple fix to the stash
failure is to check for a clean worktree after we've stashed and apply
the stash and exit if the worktree is not clean. Ideally `git stash`
would be able to tell us that it didn't stash everything, but that
warning comes from `void check_global_conv_flags_eol()` in convert.c so
it does not pass along that information to the caller.

We should also improve the cleanup code path so that it applies the
autostash (and removes the state dir) if it exists as after a quick
glance through the code it seems we might not be applying the autostash
if `git checkout`.

Best Wishes

Phillip