All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Greaves <david@dgreaves.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: [Regression] Re: setlocalversion wasn't producing git labels for bisect
Date: Sun, 31 Aug 2008 11:15:01 +0100	[thread overview]
Message-ID: <48BA6F25.8040102@dgreaves.com> (raw)
In-Reply-To: <48B9A2C7.3080001@dgreaves.com>

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



WARNING: multiple messages have this Message-ID (diff)
From: David Greaves <david@dgreaves.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki"
Subject: [Regression] Re: setlocalversion wasn't producing git labels for bisect
Date: Sun, 31 Aug 2008 11:15:01 +0100	[thread overview]
Message-ID: <48BA6F25.8040102@dgreaves.com> (raw)
In-Reply-To: <48B9A2C7.3080001@dgreaves.com>

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

  parent reply	other threads:[~2008-08-31 10:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-30 19:43 setlocalversion wasn't producing git labels for bisect David Greaves
2008-08-30 20:07 ` Junio C Hamano
2008-08-30 20:11 ` [PATCH] Fix example in git-name-rev documentation Junio C Hamano
2008-09-01 11:07   ` Johannes Schindelin
2008-08-31 10:15 ` David Greaves [this message]
2008-08-31 10:15   ` [Regression] Re: setlocalversion wasn't producing git labels for bisect David Greaves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48BA6F25.8040102@dgreaves.com \
    --to=david@dgreaves.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.