threads / discuss / 15288

setlocalversion wasn't producing git labels for bisect

Subject: setlocalversion wasn't producing git labels for bisect

## tl;dr

5 messages between Aug 30, 2008 and Sep 1, 2008.

replies: 4people: 3as markdown or json

David Greaves· Aug 30, 2008, 19:43 UTC · lore
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
Junio C Hamano· Aug 30, 2008, 20:07 UTC · re: David Greaves · lore

Re: setlocalversion wasn't producing git labels for bisect

David Greaves <david@dgreaves.com> writes:
Show 9 quoted lines
> 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.
Junio C Hamano· Aug 30, 2008, 20:11 UTC · re: David Greaves · lore

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

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
Johannes Schindelin· Sep 1, 2008, 11:07 UTC · re: Junio C Hamano · lore

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

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

David Greaves· Aug 31, 2008, 10:15 UTC · re: David Greaves · lore

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

David Greaves wrote:
Show 14 quoted lines
> 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

← back to recent threads