git bisect v2.6.27 v2.6.26 problem/bug

git bisect v2.6.27 v2.6.26 problem/bug

[Miquel van Smoorenburg]

I'm trying to nail down a disk statistics issue that was introduced
in 2.6.27, while 2.6.26 was working OK. So I decided to use git bisect.

However, sometimes I end up with a version before 2.6.26:

$ cat .git/BISECT_LOG
git-bisect start
# good: [bce7f793daec3e65ec5c5705d2457b81fe7b5725] Linux 2.6.26
git-bisect good bce7f793daec3e65ec5c5705d2457b81fe7b5725
# bad: [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27
git-bisect bad 3fa8749e584b55f1180411ab1b51117190bac1e5
# bad: [dd9ca5d9be7eba99d685d733e23d5be7110e9556] USB: usb-serial: fix a sparse warning about different signedness
git-bisect bad dd9ca5d9be7eba99d685d733e23d5be7110e9556
# good: [84c3d4aaec3338201b449034beac41635866bddf] Merge commit 'origin/master'
git-bisect good 84c3d4aaec3338201b449034beac41635866bddf

$ head -4 Makefile 
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 26
EXTRAVERSION = -rc8

If at this point I do a 'git bisect good' I end up in a 2.6.26
branch, which is good, but after a few bisects I end up at
a version before v2.6.26 (2.6.26-rc5) again, which should be
impossible right ?

Anyway - at the end I end up with a 'good' version that is
2.6.26-rc<something> which is kind of useless. I know that
version up to 2.6.26 are good ...

What am I doing wrong ?

(git version 1.5.6.5 from debian/lenny)

Mike.

Re: git bisect v2.6.27 v2.6.26 problem/bug

[Alejandro Riveira]

El Mon, 03 Nov 2008 18:39:15 +0100, Miquel van Smoorenburg escribió:

> I'm trying to nail down a disk statistics issue that was introduced in
> 2.6.27, while 2.6.26 was working OK. So I decided to use git bisect.
> 
> However, sometimes I end up with a version before 2.6.26:
> 
> $ cat .git/BISECT_LOG
> git-bisect start
> # good: [bce7f793daec3e65ec5c5705d2457b81fe7b5725] Linux 2.6.26
> git-bisect good bce7f793daec3e65ec5c5705d2457b81fe7b5725 # bad:
> [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27 git-bisect bad
> 3fa8749e584b55f1180411ab1b51117190bac1e5 # bad:
> [dd9ca5d9be7eba99d685d733e23d5be7110e9556] USB: usb-serial: fix a sparse
> warning about different signedness git-bisect bad
> dd9ca5d9be7eba99d685d733e23d5be7110e9556 # good:
> [84c3d4aaec3338201b449034beac41635866bddf] Merge commit 'origin/master'
> git-bisect good 84c3d4aaec3338201b449034beac41635866bddf
> 
> $ head -4 Makefile
> VERSION = 2
> PATCHLEVEL = 6
> SUBLEVEL = 26
> EXTRAVERSION = -rc8
> 
> If at this point I do a 'git bisect good' I end up in a 2.6.26 branch,
> which is good, but after a few bisects I end up at a version before
> v2.6.26 (2.6.26-rc5) again, which should be impossible right ?

 Afaik it is not imposible with git you do not get a linear history


> 
> Anyway - at the end I end up with a 'good' version that is
> 2.6.26-rc<something> which is kind of useless. I know that version up to
> 2.6.26 are good ...
> 
> What am I doing wrong ?
> 
> (git version 1.5.6.5 from debian/lenny)
> 
> Mike.

Re: git bisect v2.6.27 v2.6.26 problem/bug

[Linus Torvalds]

On Mon, 3 Nov 2008, Miquel van Smoorenburg wrote:
> 
> If at this point I do a 'git bisect good' I end up in a 2.6.26
> branch, which is good, but after a few bisects I end up at
> a version before v2.6.26 (2.6.26-rc5) again, which should be
> impossible right ?

No, not at all.

What is going on is that you are hitting commits that were not merged into 
2.6.26 (so they are _not_ in the "good" part), but they were _developed_ 
before it. So the kernel Makefile says "v2.6.26-rc8" (not quite 2.6.26 
yet), but that's because the version in the Makefile ends up being a 
linear explanation of what the nearest _earlier_ version was, but is not 
at all indicative of the much more complex non-linear development model.

IOW, you have history that looks like

	- A -> B -> C->
	    \     /
	     - D -

And let's say that 'A' is v2.6.26-rc8, while 'B' is the final v2.6.26 
release, and is your 'good', while 'C' is 2.6.27, and is your 'bad'.

What does that make 'D' then?

It is clearly potentially bad, because it is _not_ in the good set (it was 
merged after 2.6.26, and could very well be the source of your bug. But 
think about what 'Makefile' must contain in 'D'. 

The difference between linear history and non-linear history is very 
important, and "git bisect" very much is all about getting it right. It 
does't take a "linear" half-way point, it really does a _set_ operation, 
and it bisects the set of commits. And that set of commits is a DAG, not a 
linear series.

> Anyway - at the end I end up with a 'good' version that is
> 2.6.26-rc<something> which is kind of useless. I know that
> version up to 2.6.26 are good ...

Not at all. It's not "kind of useless", it's very important.

> What am I doing wrong ?

You're not doing anything wrong, you just didn't realize how non-linear 
development works.

			Linus