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
--
Thank you,
Brian Lyles
