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.
