Re: setlocalversion wasn't producing git labels for bisect

David Greaves [off-list ref] 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.