Hi Ben, Le 26/01/2019 à 11:16, Ben Woosley a écrit : > From: Ben Woosley <ben.woosley@xxxxxxxxx> > > To avoid partial deletion / zombie rebases. > > Example behavior under partial deletion, after > Ctrl-Cing out of a standard rebase: > > $ git rebase target > First, rewinding head to replay your work on top of it... > Applying: [...] > ^C > $ git status > rebase in progress; onto (null) > You are currently rebasing. > (all conflicts fixed: run "git rebase --continue") > > Changes to be committed: > (use "git reset HEAD <file>..." to unstage) > [...] > $ git rebase --continue > error: could not read '.git/rebase-apply/head-name': No such file or directory > $ git rebase --abort > error: could not read '.git/rebase-apply/head-name': No such file or directory > > Others report this issue here: > https://stackoverflow.com/questions/3685001/git-how-to-fix-corrupted-interactive-rebase > --- > git-legacy-rebase.sh | 17 ++++++++++++++--- > git-rebase--preserve-merges.sh | 2 +- > 2 files changed, 15 insertions(+), 4 deletions(-) > This patch does not cover the new builtin rebase, even though it’s also affected by this bug. I ran in two bugs trying to reproduce this issue with the builtin: 1. Right after invoking `git rebase $target', $target was checked out but the state directory has not been written yet, leaving the user on the target without any possibility of aborting the rebase. I think it’s because the checkout is done by builtin/rebase.c, whereas the state directory is created by git-rebase--am -- and it might not be created at all! 2. If I wait a little bit, I have the same bug as yours. I tried to reproduce the issue on master (16a465bc01, "Third batch after 2.20") and builtin.userebase set to false, without success. It seems this issue has been fixed in the shell version, but not in the builtin version -- and it seems that you are using the latter, so it won’t solve your problem anyway. Try `git -c rebase.usebuiltin=false rebase --abort', and the state directory will be removed without any errors. Things are a bit different with interactive rebase: it checks out the target branch, then create its state directory. Only the first issue can happen, and you have to be very unlucky to run into it. The same goes for rebase -p. > diff --git a/git-legacy-rebase.sh b/git-legacy-rebase.sh > index b4c7dbfa575d3..832a211c925c3 100755 > --- a/git-legacy-rebase.sh > +++ b/git-legacy-rebase.sh > @@ -128,11 +128,22 @@ read_basic_state () { > } > } > > +remove_rebase_state () { > + removal_dir=$(mktemp -d -t "git-rebase-state-XXXXXX") > + if test -d "$removal_dir" > + then > + mv "$state_dir" "$removal_dir" > + else > + removal_dir="$state_dir" > + fi > + rm -rf "$removal_dir" > +} > + > finish_rebase () { > rm -f "$(git rev-parse --git-path REBASE_HEAD)" > apply_autostash && > { git gc --auto || true; } && > - rm -rf "$state_dir" > + remove_rebase_state > } > > run_interactive () { > @@ -194,7 +205,7 @@ run_specific_rebase () { > elif test $ret -eq 2 # special exit status for rebase -p > then > apply_autostash && > - rm -rf "$state_dir" && > + remove_rebase_state && > die "Nothing to do" > fi > exit $ret > @@ -439,7 +450,7 @@ abort) > exit > ;; > quit) > - exec rm -rf "$state_dir" > + remove_rebase_state > ;; > edit-todo) > run_specific_rebase > diff --git a/git-rebase--preserve-merges.sh b/git-rebase--preserve-merges.sh > index afbb65765d461..146b52df14928 100644 > --- a/git-rebase--preserve-merges.sh > +++ b/git-rebase--preserve-merges.sh > @@ -226,7 +226,7 @@ Once you are satisfied with your changes, run > > die_abort () { > apply_autostash > - rm -rf "$state_dir" > + remove_rebase_state > die "$1" > } > > > -- > https://github.com/git/git/pull/569 > It seems that you tried to implement the solution proposed in the stackoverflow thread you linked. Unfortunately, if it fixed something, it has a problem: it won’t bring you back to the commit where you called `git rebase', unlike a `git rebase --abort' on a uncorrupted rebase state. This is what happens when aborting a corrupted rebase with the shell version of rebase. I think it’s because git-rebase--am will only create a state directory if it has a problem (ie. a conflict or the user hits ^C). So, there is definitely a problem with git-rebase--am, but this does not address it. -- Alban
