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

[Linus Torvalds <torvalds@linux-foundation.org>]

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