Re: [PATCH v2 11/11] rebase: dereference tags
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 14, 2021, 16:29 UTC
- Message-ID
- <xmqqbl4v3yun.fsf@gitster.g>
- In-Reply-To
- <8c78eac4-676b-7bd1-0282-d52eb20f87ce@gmail.com>
Phillip Wood <phillip.wood123@gmail.com> writes:
Show 12 quoted lines
>>> Did we auto-peel in scripted version of "git rebase" and is this a >>> regression when the command was rewritten in C? >> As far as I can tell we have never peeled tags here > > That's a bit misleading. We have never peeled a tag given as <branch> > when we parse it. In the scripted version we just passed the tag oid > along to rev-list, checkout and reset and they peeled it. So I think > this is actually a regression in the builtin rebase. I'll update the > commit message to reflect that unless we feel that allowing a tag for > <branch> is a mistake and we should be erroring out to avoid the > possible confusion of the tag not being rebased, only the commits it > points to.
OK, so this is a regression fix. That makes the change much simpler to sell. I'd expect that the description would be along the lines of something like this, perhaps.
A rebase started with 'git rebase <A> <B>' is conceptually to
first checkout <B> and run 'git rebase <A>' starting from that
state. 'git rebase --abort' 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 X.Y.Z when the command was reimplemented in C.
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 doing ....
Thanks for digging (and fixing, of course).