Try to follow the advice you see on the screen, and first reset your master's HEAD to the commit it expects.
git update-ref refs/heads/master b918ac16a33881ce00799bea63d9c23bf7022d67
Then, abort the rebase again.
With Git 2.34 (Q4 2021), a git rebase --abort
should be more reliable:
"git rebase <upstream> <tag>
"(man) failed when aborted in the middle, as it mistakenly tried to write the tag object instead of peeling it to HEAD.
See commit 7740ac6, commit 1d18826, commit 35f070b (21 Sep 2021), and commit d045719, commit 1e14bc1, commit 0b7ae73, commit 54627db, commit 7390c65, commit e505f45, commit f20c1fb (13 Sep 2021) by Phillip Wood (phillipwood
).
(Merged by Junio C Hamano -- gitster
-- in commit 7cebe73, 06 Oct 2021)
rebase
: dereference tagsSigned-off-by: Phillip Wood
A rebase started with '
git rebase <A> <B>
'(man) is conceptually to firstcheckout <B>
and rungit rebase <A>
starting from that state.
'git rebase --abort
'(man) in the middle of such a rebase should take us back to the state we checked out<B>
.This used to work, even when
<B>
is a tag that points at a commit, until Git 2.20.0 when the command was reimplemented inC
.
The command now complains that the tag object itself cannot be checked out, which may be technically correct but is not what the user asked to do.Fix this old regression by using
lookup_commit_reference_by_name()
when parsing<B>
.
The scripted version did not need to peel the tag because the commands it passed the tag to (e.g 'git reset
'(man)) peeled the tag themselves.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With