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

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

[SZEDER Gábor]

That's a good subject, isn't it? :)

So, to clarify: apparently it is possible to abort an ongoing 'git
rebase' process with ctrl-C in just the right moment that a subsequent
'git rebase --abort' will refuse to clear it up.

I somehow messed up the upstream and branch parameters of 'git
rebase', and ended up trying to rebase a fairly recent (post v2.24.0)
branch on top of v2.22.0.  Upon seeing the unexpectedly large number
of patches I realized that something is wrong, hit ctrl-C right away,
and this is what happened:

  $ git rebase v2.22.0 <a-branch-on-top-of-2.24.0>
  First, rewinding head to replay your work on top of it...
  Generating patches: 100% (1108/1108), done.
  Applying: send-email: move the read_config() function above getopts
  Applying: send-email: rename the @bcclist variable for consistency
  Applying: send-email: do defaults -> config -> getopt in that order
  Using index info to reconstruct a base tree...
  M       git-send-email.perl
  M       t/t9001-send-email.sh
  Falling back to patching base and 3-way merge...
  Auto-merging t/t9001-send-email.sh
  Auto-merging git-send-email.perl
  ^C
  ((5f07da12ac...) *|REBASE 3/1108)$ git rebase --abort 
  error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory
   
"Fortunately" it was in a separate worktree, so I could easily get out
of the situation by forcibly deleting that worktree.  Unfortunately,
that was exactly what I did, instead of securing the failed state for
later analysis...  sorry.
The only thing I still have is the list of files in the rebase directory,
rescued from the terminal's scrollback buffer:

  $ ls ~/src/git/.git/worktrees/WT/rebase-apply/
  < ... omitting the 1k+ patch files ... >
  abort-safety
  apply-opt
  author-script
  final-commit
  keep
  last
  messageid
  next
  original-commit
  patch
  patch-merge-index
  quiet
  rebasing
  rewritten
  scissors
  sign
  threeway
  utf8

All this is with a git built from current 'next', with a bunch of
unrelated (none of them touches rebase or the sequencer) patches on
top.

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

[SZEDER Gábor]

On Fri, Feb 07, 2020 at 12:10:08PM +0100, SZEDER Gábor wrote:
> That's a good subject, isn't it? :)
> 
> So, to clarify: apparently it is possible to abort an ongoing 'git
> rebase' process with ctrl-C in just the right moment that a subsequent
> 'git rebase --abort' will refuse to clear it up.
> 
> I somehow messed up the upstream and branch parameters of 'git
> rebase', and ended up trying to rebase a fairly recent (post v2.24.0)
> branch on top of v2.22.0.  Upon seeing the unexpectedly large number
> of patches I realized that something is wrong, hit ctrl-C right away,
> and this is what happened:
> 
>   $ git rebase v2.22.0 <a-branch-on-top-of-2.24.0>
>   First, rewinding head to replay your work on top of it...
>   Generating patches: 100% (1108/1108), done.
>   Applying: send-email: move the read_config() function above getopts
>   Applying: send-email: rename the @bcclist variable for consistency
>   Applying: send-email: do defaults -> config -> getopt in that order
>   Using index info to reconstruct a base tree...
>   M       git-send-email.perl
>   M       t/t9001-send-email.sh
>   Falling back to patching base and 3-way merge...
>   Auto-merging t/t9001-send-email.sh
>   Auto-merging git-send-email.perl
>   ^C
>   ((5f07da12ac...) *|REBASE 3/1108)$ git rebase --abort 
>   error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory
>    
> "Fortunately" it was in a separate worktree, so I could easily get out
> of the situation by forcibly deleting that worktree.  Unfortunately,
> that was exactly what I did, instead of securing the failed state for
> later analysis...  sorry.

> All this is with a git built from current 'next', with a bunch of
> unrelated (none of them touches rebase or the sequencer) patches on
> top.

Trying to reproduce it is a hit or miss... well, mostly miss :)

There is a rather short window when 'git rebase' applies patches
before hitting a first merge conflict.  If the ctrl-C arrives before
'git rebase' starts applying patches, then it cleans everything up,
and we are not rebasing, so there is no need for 'git rebase --abort'.
Once 'git rebase' stops because of the merge conflict we get our shell
back, and 'git rebase --abort' works as it should.  But after a good
couple of tries I managed to hit ctrl-C while 'git rebase' was
applying patches:

  $ ./BUILDS/v2.25.0/bin/git rebase v2.22.0 v2.24.0^{commit}
  First, rewinding head to replay your work on top of it...
  Generating patches: 100% (1049/1049), done.
  Applying: send-email: move the read_config() function above getopts
  ^C
  ((v2.22.0) +|REBASE 1/1049)$ ./BUILDS/v2.25.0/bin/git rebase --abort
  error: could not read '.git/rebase-apply/head-name': No such file or directory

Note that I'm using v2.25.0 here, so the problem is not with 'next' or
with my patches.  Also note that I reproduced the error in the main
worktree, and only using commits that are present in git.git.


Finally, note the 'v2.24.0^{commit}' parameter, in particular the
'^{commit}' part.  That's important, because without it we stumble
upon _another_ bug:

  $ git rebase v2.22.0 v2.24.0
  error: Object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 not a commit
  First, rewinding head to replay your work on top of it...
  Generating patches: 100% (1049/1049), done.
  Applying: send-email: move the read_config() function above getopts
  < ... applying further patches and hitting a merge conflict ... >
  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".
  (detached HEAD *+|REBASE 7/1049)$ git rebase --abort 
  error: update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 to branch 'HEAD'

So 'git rebase' shows an error right at the beginning when rebasing a
tag, but then continues anyway.  However, 'git rebase --abort' can't
restore the original state.

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

[SZEDER Gábor]

On Fri, Feb 07, 2020 at 12:49:54PM +0100, SZEDER Gábor wrote:
> On Fri, Feb 07, 2020 at 12:10:08PM +0100, SZEDER Gábor wrote:
> > That's a good subject, isn't it? :)
> > 
> > So, to clarify: apparently it is possible to abort an ongoing 'git
> > rebase' process with ctrl-C in just the right moment that a subsequent
> > 'git rebase --abort' will refuse to clear it up.
> > 
> > I somehow messed up the upstream and branch parameters of 'git
> > rebase', and ended up trying to rebase a fairly recent (post v2.24.0)
> > branch on top of v2.22.0.  Upon seeing the unexpectedly large number
> > of patches I realized that something is wrong, hit ctrl-C right away,
> > and this is what happened:
> > 
> >   $ git rebase v2.22.0 <a-branch-on-top-of-2.24.0>
> >   First, rewinding head to replay your work on top of it...
> >   Generating patches: 100% (1108/1108), done.
> >   Applying: send-email: move the read_config() function above getopts
> >   Applying: send-email: rename the @bcclist variable for consistency
> >   Applying: send-email: do defaults -> config -> getopt in that order
> >   Using index info to reconstruct a base tree...
> >   M       git-send-email.perl
> >   M       t/t9001-send-email.sh
> >   Falling back to patching base and 3-way merge...
> >   Auto-merging t/t9001-send-email.sh
> >   Auto-merging git-send-email.perl
> >   ^C
> >   ((5f07da12ac...) *|REBASE 3/1108)$ git rebase --abort 
> >   error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory
> >    
> > "Fortunately" it was in a separate worktree, so I could easily get out
> > of the situation by forcibly deleting that worktree.  Unfortunately,
> > that was exactly what I did, instead of securing the failed state for
> > later analysis...  sorry.
> 
> > All this is with a git built from current 'next', with a bunch of
> > unrelated (none of them touches rebase or the sequencer) patches on
> > top.
> 
> Trying to reproduce it is a hit or miss... well, mostly miss :)
> 
> There is a rather short window when 'git rebase' applies patches
> before hitting a first merge conflict.  If the ctrl-C arrives before
> 'git rebase' starts applying patches, then it cleans everything up,
> and we are not rebasing, so there is no need for 'git rebase --abort'.
> Once 'git rebase' stops because of the merge conflict we get our shell
> back, and 'git rebase --abort' works as it should.  But after a good
> couple of tries I managed to hit ctrl-C while 'git rebase' was
> applying patches:

This patch below increases the size of the window where a ctrl-C gets
us into that problematic situation:

diff --git a/builtin/am.c b/builtin/am.c
index 8181c2aef3..5d62766000 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -1737,6 +1737,14 @@ static void am_run(struct am_state *state, int resume)
 			exit(1);
 
 		say(state, stdout, _("Applying: %.*s"), linelen(state->msg), state->msg);
+		{
+			int i;
+			for (i = 0; i < 60; i++) {
+				fprintf(stderr, "sleeping... %d\r", i);
+				sleep(1);
+			}
+			fprintf(stderr, "\n");
+		}
 
 		apply_status = run_apply(state, NULL);
 
And then we can reliably reproduce the issue even when rebasing only a
single commit:

  $ ./bin-wrappers/git rebase v2.25.0 9c8a294
  First, rewinding head to replay your work on top of it...
  Applying: sha1-file: remove OBJECT_INFO_SKIP_CACHED
  ^Ceeping... 3
  ((v2.25.0)|REBASE 1/1)$ ./bin-wrappers/git rebase --abort 
  error: could not read '.git/rebase-apply/head-name': No such file or directory

Note that the sleep() calls were added to 'builtin/am.c', i.e. this
issue is present in the 'am' rebase backend.  I tried to break 'git
rebase -m ...' by adding sleep()s to various places in pick_commits()
in 'sequencer.c', but, FWIW, the subsequent 'git rebase --abort'
always worked as expected.

So we may have yet another reason to switch the default rebase backend
from 'am' to 'merge'.


> Finally, note the 'v2.24.0^{commit}' parameter, in particular the
> '^{commit}' part.  That's important, because without it we stumble
> upon _another_ bug:
> 
>   $ git rebase v2.22.0 v2.24.0
>   error: Object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 not a commit
>   First, rewinding head to replay your work on top of it...
>   Generating patches: 100% (1049/1049), done.
>   Applying: send-email: move the read_config() function above getopts
>   < ... applying further patches and hitting a merge conflict ... >
>   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".
>   (detached HEAD *+|REBASE 7/1049)$ git rebase --abort 
>   error: update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 to branch 'HEAD'
> 
> So 'git rebase' shows an error right at the beginning when rebasing a
> tag, but then continues anyway.  However, 'git rebase --abort' can't
> restore the original state.

Now let's rebase a tag with the 'merge' backend, and then try to abort
it:

  $ ./BUILDS/v2.25.0/bin/git rebase -m v2.22.0 v2.24.0
  error: Object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 not a commit
  Auto-merging t/t9001-send-email.sh
  Auto-merging git-send-email.perl
  CONFLICT (content): Merge conflict in git-send-email.perl
  Auto-merging Documentation/git-send-email.txt
  error: could not apply 3ff15040e2... send-email: fix regression in sendemail.identity parsing
  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".
  Recorded preimage for 'git-send-email.perl'
  Could not apply 3ff15040e2... send-email: fix regression in sendemail.identity parsing
  (detached HEAD *+|REBASE 7/1049)$ ./BUILDS/v2.25.0/bin/git rebase --abort
  ((v2.24.0))$

So it prints the same error as the 'am' backend (or perhaps that error
comes from the common, backend-independent parts of rebase?  I didn't
look), and it continues all the same, but in the end '--abort' is
capable to abort the operation.  So we do have yet another reason to
switch the default backend.

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

[Elijah Newren]

On Fri, Feb 7, 2020 at 5:21 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
>
> On Fri, Feb 07, 2020 at 12:49:54PM +0100, SZEDER Gábor wrote:
> > On Fri, Feb 07, 2020 at 12:10:08PM +0100, SZEDER Gábor wrote:
> > > That's a good subject, isn't it? :)

Indeed.  :-)

> > > So, to clarify: apparently it is possible to abort an ongoing 'git
> > > rebase' process with ctrl-C in just the right moment that a subsequent
> > > 'git rebase --abort' will refuse to clear it up.
> > >
> > > I somehow messed up the upstream and branch parameters of 'git
> > > rebase', and ended up trying to rebase a fairly recent (post v2.24.0)
> > > branch on top of v2.22.0.  Upon seeing the unexpectedly large number
> > > of patches I realized that something is wrong, hit ctrl-C right away,
> > > and this is what happened:
> > >
> > >   $ git rebase v2.22.0 <a-branch-on-top-of-2.24.0>
> > >   First, rewinding head to replay your work on top of it...
> > >   Generating patches: 100% (1108/1108), done.
> > >   Applying: send-email: move the read_config() function above getopts
> > >   Applying: send-email: rename the @bcclist variable for consistency
> > >   Applying: send-email: do defaults -> config -> getopt in that order
> > >   Using index info to reconstruct a base tree...
> > >   M       git-send-email.perl
> > >   M       t/t9001-send-email.sh
> > >   Falling back to patching base and 3-way merge...
> > >   Auto-merging t/t9001-send-email.sh
> > >   Auto-merging git-send-email.perl
> > >   ^C
> > >   ((5f07da12ac...) *|REBASE 3/1108)$ git rebase --abort
> > >   error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory
> > >
> > > "Fortunately" it was in a separate worktree, so I could easily get out
> > > of the situation by forcibly deleting that worktree.  Unfortunately,
> > > that was exactly what I did, instead of securing the failed state for
> > > later analysis...  sorry.
> >
> > > All this is with a git built from current 'next', with a bunch of
> > > unrelated (none of them touches rebase or the sequencer) patches on
> > > top.
> >
> > Trying to reproduce it is a hit or miss... well, mostly miss :)
> >
> > There is a rather short window when 'git rebase' applies patches
> > before hitting a first merge conflict.  If the ctrl-C arrives before
> > 'git rebase' starts applying patches, then it cleans everything up,
> > and we are not rebasing, so there is no need for 'git rebase --abort'.
> > Once 'git rebase' stops because of the merge conflict we get our shell
> > back, and 'git rebase --abort' works as it should.  But after a good
> > couple of tries I managed to hit ctrl-C while 'git rebase' was
> > applying patches:
>
> This patch below increases the size of the window where a ctrl-C gets
> us into that problematic situation:
>
> diff --git a/builtin/am.c b/builtin/am.c
> index 8181c2aef3..5d62766000 100644
> --- a/builtin/am.c
> +++ b/builtin/am.c
> @@ -1737,6 +1737,14 @@ static void am_run(struct am_state *state, int resume)
>                         exit(1);
>
>                 say(state, stdout, _("Applying: %.*s"), linelen(state->msg), state->msg);
> +               {
> +                       int i;
> +                       for (i = 0; i < 60; i++) {
> +                               fprintf(stderr, "sleeping... %d\r", i);
> +                               sleep(1);
> +                       }
> +                       fprintf(stderr, "\n");
> +               }
>
>                 apply_status = run_apply(state, NULL);
>
> And then we can reliably reproduce the issue even when rebasing only a
> single commit:
>
>   $ ./bin-wrappers/git rebase v2.25.0 9c8a294
>   First, rewinding head to replay your work on top of it...
>   Applying: sha1-file: remove OBJECT_INFO_SKIP_CACHED
>   ^Ceeping... 3
>   ((v2.25.0)|REBASE 1/1)$ ./bin-wrappers/git rebase --abort
>   error: could not read '.git/rebase-apply/head-name': No such file or directory
>
> Note that the sleep() calls were added to 'builtin/am.c', i.e. this
> issue is present in the 'am' rebase backend.  I tried to break 'git
> rebase -m ...' by adding sleep()s to various places in pick_commits()
> in 'sequencer.c', but, FWIW, the subsequent 'git rebase --abort'
> always worked as expected.
>
> So we may have yet another reason to switch the default rebase backend
> from 'am' to 'merge'.
>
>
> > Finally, note the 'v2.24.0^{commit}' parameter, in particular the
> > '^{commit}' part.  That's important, because without it we stumble
> > upon _another_ bug:
> >
> >   $ git rebase v2.22.0 v2.24.0
> >   error: Object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 not a commit
> >   First, rewinding head to replay your work on top of it...
> >   Generating patches: 100% (1049/1049), done.
> >   Applying: send-email: move the read_config() function above getopts
> >   < ... applying further patches and hitting a merge conflict ... >
> >   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".
> >   (detached HEAD *+|REBASE 7/1049)$ git rebase --abort
> >   error: update_ref failed for ref 'HEAD': cannot update ref 'HEAD': trying to write non-commit object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 to branch 'HEAD'
> >
> > So 'git rebase' shows an error right at the beginning when rebasing a
> > tag, but then continues anyway.  However, 'git rebase --abort' can't
> > restore the original state.
>
> Now let's rebase a tag with the 'merge' backend, and then try to abort
> it:
>
>   $ ./BUILDS/v2.25.0/bin/git rebase -m v2.22.0 v2.24.0
>   error: Object 1cc4bc0fcd93f816d514d77c29f2cc9ffdd8ae09 not a commit
>   Auto-merging t/t9001-send-email.sh
>   Auto-merging git-send-email.perl
>   CONFLICT (content): Merge conflict in git-send-email.perl
>   Auto-merging Documentation/git-send-email.txt
>   error: could not apply 3ff15040e2... send-email: fix regression in sendemail.identity parsing
>   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".
>   Recorded preimage for 'git-send-email.perl'
>   Could not apply 3ff15040e2... send-email: fix regression in sendemail.identity parsing
>   (detached HEAD *+|REBASE 7/1049)$ ./BUILDS/v2.25.0/bin/git rebase --abort
>   ((v2.24.0))$
>
> So it prints the same error as the 'am' backend (or perhaps that error
> comes from the common, backend-independent parts of rebase?  I didn't
> look), and it continues all the same, but in the end '--abort' is
> capable to abort the operation.  So we do have yet another reason to
> switch the default backend.

Ooh, interesting; thanks for investigating and providing a heads up.
I should probably add a note about this to the "differences between
backends"; I'll roll it into whatever changes I might need to make
with Phillip's review of the series.

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

[Junio C Hamano]

Phillip Wood <phillip.wood123@gmail.com> 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.

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

[Phillip Wood]

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

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

[Thomas Braun]

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:

#!/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.

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

[Elijah Newren]

Hi,

On Sat, May 30, 2020 at 3:52 AM Md Naeim <naeim249@gmail.com> 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.