# Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase 4 messages from 2020-05-30 to 2020-06-05. Participants: Elijah Newren, Thomas Braun, Phillip Wood, Junio C Hamano. Thread: https://gitlist.dev/t/53584 ## Elijah Newren, 2020-05-30 16:24 Subject: Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase Message-ID: URL: https://gitlist.dev/e/CABPp-BGh0T1xio-pRb%3DJVNbJDK1PWpo%2Bv877nDfjcm6khn6NDg%40mail.gmail.com In-Reply-To: ``` Hi, On Sat, May 30, 2020 at 3:52 AM Md Naeim wrote: > > > > 01718479491 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. ``` ## Thomas Braun, 2020-06-03 16:09 Subject: Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase Message-ID: <63139842-8548-6c64-1214-5469eedb8d4f@virtuell-zuhause.de> URL: https://gitlist.dev/e/63139842-8548-6c64-1214-5469eedb8d4f%40virtuell-zuhause.de In-Reply-To: ``` On 30.05.2020 18:24, Elijah Newren wrote: > On Sat, May 30, 2020 at 3:52 AM Md Naeim 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: #!/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. error: Please commit or stash them. error: could not read '.git/rebase-merge/head-name': No such file or directory 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. 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. ``` ## Phillip Wood, 2020-06-04 10:19 Subject: Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase Message-ID: URL: https://gitlist.dev/e/b83568b8-e465-243e-cd84-eba88c4e95d9%40gmail.com In-Reply-To: <63139842-8548-6c64-1214-5469eedb8d4f@virtuell-zuhause.de> ``` 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 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 ``` ## Junio C Hamano, 2020-06-05 15:29 Subject: Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase Message-ID: URL: https://gitlist.dev/e/xmqqpnado7jc.fsf%40gitster.c.googlers.com In-Reply-To: ``` Phillip Wood writes: >> 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. The suggested fix covers all cases where the auto-stash step fails to revert the index and the working tree to the prestine state for any reason, not limited to the eol normalization. It is not just a simple but necessary fix, regardless of what other things we do. Why doesn't the internal "stash" fail to clean the index and the working tree to pristine state in the first place, though? It may be another thing that needs fixing, but in a sense, that is of secondary importance. Thanks. ```