git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 5, 2020, 15:29 UTC
Message-ID
<xmqqpnado7jc.fsf@gitster.c.googlers.com>
In-Reply-To
<b83568b8-e465-243e-cd84-eba88c4e95d9@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 7 quoted lines
>> 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.
Previous: Phillip Wood
Message 4 of 4 in “Re: [BUG?] 'git rebase --abort' couldn't abort aborted rebase”
  1. Elijah NewrenMay 30, 2020
  2. Thomas BraunJun 3, 2020
  3. Phillip WoodJun 4, 2020
  4. Junio C HamanoJun 5, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.