Subject: Re: setlocalversion wasn't producing git labels for bisect

From: Junio C Hamano <[email-masked]>
Date: Sat, 30 Aug 2008 13:07:56 -0700

David Greaves <[email-masked]> writes:

> Running
>   git name-rev --tags HEAD
> gives the output
>   HEAD tags/v2.6.27-rc4~44^2
>
> This isn't matched by setlocalversion regexp so it makes it harder to make deb-pkg/install/grub/reboot/remove
>
> Of course if this patch is accepted it is going to make life complicated when bisecting around it.
> Maybe git should behave as the man page suggests and have the ^X before the ~nnn? (maybe it has been fixed already)

Sorry, I don't understand what you are trying to fix here.

Your head can be reached by going 44 generations back (following the first
parent chain) from v2.6.27-rc4, which is a merge commit, and then taking
its second parent.  IOW the name-rev output you quoted represents this
history:

                                  v2.6.27-rc4
       ----o---o---o---....---o---o
          /^                  ^
         / v2.6.27-rc4~44     v2.6.27-rc4~1
        o
        ^ Your HEAD

Swapping ^X and ~nnn changes the meaning completely.  v2.6.27-rc4^2~44 is
the 44 generation ancestor of the second parent of -rc4, but v2.6.27-rc4
is *NOT* a merge and it does not have the second parent.

>   http://www.kernel.org/pub/software/scm/git/docs/v1.5.6.5/git-name-rev.html
> shows an example:
>   33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940

This says

    v0.99 is a tag, and dereference it (^0) to get to the commit that
    points at it, and then the commit in question (33db5f) is its 940th
    generation ancestor.

We used to explicitly say "it is a tag and dereference it" by adding ^0
but since Feb 2007 we stopped doing so because taking its 940th parent
can only be done to a commit, so v0.99~940 and v0.99^0~940 are equivalent.

We should fix the documentation, though.