[BUG REPORT] `--autostash` rebase + pre-rebase error ends in corrupt state

If you perform a rebase using `--autostash`, and the pre-rebase hook exits with a non-zero exit code, your worktree is left in some sort of invalid state. This is reproducible with the following script:

    git init --initial-branch main
    echo -e '#!/bin/sh\nexit 1' > .git/hooks/pre-rebase
    chmod +x .git/hooks/pre-rebase
    
    git commit --allow-empty -m "initial commit"
    
    git switch -c feature1 main
    
    touch a.txt
    git add a.txt
    git commit -m "add a"
    
    git switch -c feature2 main
    
    touch b.txt
    git add b.txt
    git commit -m "add b"
    
    echo "content" > b.txt
    git rebase --autostash feature1

At this point, `git status` indicates that you are rebasing and `__git_ps1` also shows simply `(|REBASE)`. However, attempting to `git rebase --abort` or `git rebase --continue` gives "warning: could not read '.git/rebase-merge/head-name': No such file or directory", and does not appear to change the worktree state.

You're able to recover from this by using `git rebase --quit` and then resetting to the commit you were on before attempting the rebase.

This issue only occurs if there is actually some modification to stash; the presence of `--autostash` by itself does not trigger it.

If the above script is adjusted to make no uncommitted modifications, and rebase without using `--autostash`, then the rebase is simply aborted as expected when the pre-rebase hook fails.

I've reproduced this in the following OS/git version combinations:

- Gentoo Linux, git v2.46.0
- MacOS Sonoma 14.5, git v2.46.0
- Windows 11, git 2.44.0.windows.1

Hi Brian

On 09/08/2024 20:29, Brian Lyles wrote:

Thanks for reporting this. It looks like the rebase code was written on the assumption that we only write the state files after successfully checking out the commit we're rebasing onto. Unfortunately "--autostash" breaks that assumption as it creates the autostash state file much earlier leading to an inconsistent state if the rebase cannot start. I'll post a fix later this week.

I don't think you should need to reset HEAD as it should be untouched. You can get the stashed changes back by running "git stash --apply" with the oid from the "Created autostash: ..." line that rebase prints.

Best Wishes

Phillip