setlocalversion wasn't producing git labels for bisect

setlocalversion wasn't producing git labels for bisect

[David Greaves]

Trying to do a bisect with git version 1.5.6.3 didn't work with the setlocalversion script

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

David

commit 511c5f04eb2df03dbbae97ede82913da1f141f86
Author: David Greaves <david@dgreaves.com>
Date:   Sat Aug 30 14:53:35 2008 +0100

    setlocalversion wasn't producing git labels for bisect

diff --git a/scripts/setlocalversion b/scripts/setlocalversion
index 83b7512..89f126d 100755
--- a/scripts/setlocalversion
+++ b/scripts/setlocalversion
@@ -11,7 +11,7 @@ cd "${1:-.}" || usage
 # Check for git and a git repo.
 if head=`git rev-parse --verify HEAD 2>/dev/null`; then
 	# Do we have an untagged version?
-	if git name-rev --tags HEAD | grep -E '^HEAD[[:space:]]+(.*~[0-9]*|undefined)$' > /dev/null; then
+	if git name-rev --tags HEAD | grep -E '^HEAD[[:space:]]+(.*~[0-9^]*|undefined)$' > /dev/null; then
 		if tag=`git describe 2>/dev/null`; then
 			echo $tag | awk -F- '{printf("-%05d-%s", $(NF-1),$(NF))}'
 		fi

Re: setlocalversion wasn't producing git labels for bisect

[Junio C Hamano]

David Greaves <david@dgreaves.com> 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.

[PATCH] Fix example in git-name-rev documentation

[Junio C Hamano]

Since 59d3f54 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev
stopped showing an unnecessary "^0" to dereference a tag down to a commit.
The patch should have made a matching update to the documentation, but we
forgot.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-name-rev.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Documentation/git-name-rev.txt b/Documentation/git-name-rev.txt
index abd2237..7ca8a7b 100644
--- a/Documentation/git-name-rev.txt
+++ b/Documentation/git-name-rev.txt
@@ -59,7 +59,7 @@ Enter 'git-name-rev':
 
 ------------
 % git name-rev 33db5f4d9027a10e477ccf054b2c1ab94f74c85a
-33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99^0~940
+33db5f4d9027a10e477ccf054b2c1ab94f74c85a tags/v0.99~940
 ------------
 
 Now you are wiser, because you know that it happened 940 revisions before v0.99.
-- 
1.6.0.1.162.g04bc

[Regression] Re: setlocalversion wasn't producing git labels for bisect

[David Greaves]

David Greaves wrote:

> Trying to do a bisect with git version 1.5.6.3 didn't work with the setlocalversion script
>
> 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)
>   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
OK, I apologise if I'm being dim.
I use git to get source for all my kernels on all my various machines. Rather than have them all pull from kernel.org I have a local mirror setup that also merges in the stable branches so I can get any tag without hitting the WAN.

When I do

cd /usr/src/linux-git/

git reset --hard v2.6.27-rc5

git bisect start

git bisect bad v2.6.27-rc4

git bisect good v2.6.27-rc3
zcat /proc/config.gz > .config

make oldconfig

make include/config/kernel.release

$ cat include/config/kernel.release
2.6.27-rc3

I think this should be a -git<nnnnn>

OK I have just done a fresh clone and tried it on that - it's nothing to do with my merged setup. I've also asked on irc and someone else had the problem too.

So now I think setlocalversion should be (at least)
+    if git name-rev --tags HEAD | grep -E '^HEAD[[:space:]]+(.*[0-9^~]*|undefined)$' > /dev/null; then

I'm cc'ing the git group since I suspect this is to do with branches or rebases or something arcane and it would be good to get the regexp right.
The git-rev-parse manpage talks about many other formats but it's not easy to see which are valid input and which are possible output.
I also wondered about using git rev-parse in the script but I'm not sure.
 [ -z `git tag -l \`git name-rev --name-only --tags HEAD\`` ]
sprang to mind but I'm still getting ^0 on the end of name-rev in 1.5.6.3 and of course older git versions won't work.


In any case I think bisecting using localversion is broken around this point... I'll get on it manually for the actual bug I've got :)

David

Re: [PATCH] Fix example in git-name-rev documentation

[Johannes Schindelin]

Hi,

On Sat, 30 Aug 2008, Junio C Hamano wrote:

> Since 59d3f54 (name-rev: avoid "^0" when unneeded, 2007-02-20), name-rev
> stopped showing an unnecessary "^0" to dereference a tag down to a commit.
> The patch should have made a matching update to the documentation, but we
> forgot.

ACK & sorry,
Dscho