Re: [PATCH v2 11/11] rebase: dereference tags

Phillip Wood [off-list ref] writes:

quoted

quoted

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).