Problem with git bisect in git-1.6.3.3

Hi,

I'm using git bisect to track down a problem in 2.6.31-rc2 that is
locking up my laptop. I get so far in the bisection process and then
end up building a kernel that seems to me to be outside the good..bad
range. First time up I thought it might be a case of PBKAC, but I've
run the process again (very carefully) and got to the same place.

The bisect log so far:

[chris:~/kernel/linux-2.6]$ git bisect log
git bisect start
# good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
# bad: [8e4a718ff38d8539938ec3421935904c27e00c39] Linux 2.6.31-rc2
git bisect bad 8e4a718ff38d8539938ec3421935904c27e00c39
# good: [e7c5a4f292e0d1f4ba9a3a94b2c8e8b71e35b25a] powerpc/5121: make
clock debug output more readable
git bisect good e7c5a4f292e0d1f4ba9a3a94b2c8e8b71e35b25a
# bad: [d23c45fd84f79a3b84899dac053dcafe9d43ebc9] NFS: Invalid mount
option values should always fail, even with "sloppy"
git bisect bad d23c45fd84f79a3b84899dac053dcafe9d43ebc9
# bad: [2ed0e21b30b53d3a94e204196e523e6c8f732b56] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
git bisect bad 2ed0e21b30b53d3a94e204196e523e6c8f732b56

but, from Makefile, it appears the last "bad" has placed me at a
change earlier than 2.6.30:

[chris:~/kernel/linux-2.6]$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc6
NAME = Vindictive Armadillo

# *DOCUMENTATION*
# To see a list of typical targets execute "make help"
# More info can be located in ./README
# Comments in this file are targeted only to the developer, do not

I'm not an experienced git user, so it may be that I have made an
error or false assumption. I guess it's also possible that I've
screwed my repository, although basically I only use two types of
command - pull a few times a week and the bisect family when I'm
trying to track down a problem.

Come to think of it, I did archive the repository (with tar | bzip2)
about a week ago whilst I changed the hard drive in my laptop. Once
the new drive was installed, I restored the repository and freshened
it up with a git pull. Could this be the root of my problem, please?

Happy to provide more information if needed. Please cc me to any reply
- I'm not subscribed.

Thanks

Chris

-- 
No, Sir; there is nothing which has yet been contrived by man, by
which so much happiness is produced as by a good tavern or inn -
Doctor Samuel Johnson

Chris Clayton schrieb:

git bisect start
# good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
# bad: [8e4a718ff38d8539938ec3421935904c27e00c39] Linux 2.6.31-rc2

...

but, from Makefile, it appears the last "bad" has placed me at a
change earlier than 2.6.30:

[chris:~/kernel/linux-2.6]$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc6

...

I'm not an experienced git user, so it may be that I have made an
error or false assumption.

Not an error, but false assumptions:

http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977

Just continue bisecting. If you can't test the version that bisect warps
you to because the feature where the bug happens is not present, mark that
revision as "good".

-- Hannes

Hannes,

Thanks for your reply.

2009/7/9 Johannes Sixt [off-list ref]:

Chris Clayton schrieb:

quoted

git bisect start
# good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
# bad: [8e4a718ff38d8539938ec3421935904c27e00c39] Linux 2.6.31-rc2

...

quoted

but, from Makefile, it appears the last "bad" has placed me at a
change earlier than 2.6.30:

[chris:~/kernel/linux-2.6]$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc6

...

quoted

I'm not an experienced git user, so it may be that I have made an
error or false assumption.

Not an error, but false assumptions:

http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977

Just continue bisecting. If you can't test the version that bisect warps
you to because the feature where the bug happens is not present, mark that
revision as "good".

Ah, it makes sense now. Thanks for your help.

Chris

-- Hannes

-- 
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson

On Thursday 09 July 2009, Johannes Sixt wrote:

Chris Clayton schrieb:

quoted

git bisect start
# good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
# bad: [8e4a718ff38d8539938ec3421935904c27e00c39] Linux 2.6.31-rc2

...

quoted

but, from Makefile, it appears the last "bad" has placed me at a
change earlier than 2.6.30:

[chris:~/kernel/linux-2.6]$ head Makefile
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc6

...

quoted

I'm not an experienced git user, so it may be that I have made an
error or false assumption.

Not an error, but false assumptions:

http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977

Just continue bisecting. If you can't test the version that bisect warps
you to because the feature where the bug happens is not present, mark
that revision as "good".

For information, I added the following very short FAQ entry:

http://git.or.cz/gitwiki/GitFaq#Whydoes.22gitbisect.22makesmetestversionsoutsidethe.22good-bad.22range.3F

Thanks,
Christian.