From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Git Mailing List <git@vger.kernel.org>
Subject: [BUG?] 'git rebase --abort' couldn't abort aborted rebase
Date: Fri, 7 Feb 2020 12:10:08 +0100 [thread overview]
Message-ID: <20200207111008.GA2868@szeder.dev> (raw)
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.
next reply other threads:[~2020-02-07 11:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 11:10 SZEDER Gábor [this message]
2020-02-07 11:49 ` [BUG?] 'git rebase --abort' couldn't abort aborted rebase SZEDER Gábor
2020-02-07 13:21 ` SZEDER Gábor
2020-02-07 17:52 ` Elijah Newren
[not found] <CADhmr77EbC+3f=Oa+bm18Z_SSEMK8vCjNHQniuvkdfaZdRT_5A@mail.gmail.com>
2020-05-30 16:24 ` Elijah Newren
2020-06-03 16:09 ` Thomas Braun
2020-06-04 10:19 ` Phillip Wood
2020-06-05 15:29 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200207111008.GA2868@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.