Re: 2.6.29-rc8: Reported regressions from 2.6.28

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

On Mon, 16 Mar 2009, Jeff Chua wrote:
> 
> Take the attached bisect log and replay it

Taking a bisect log is repeatable, but pointless.

If you made any mistakes in bisecting (marking a kernel that was good as 
being bad, or the other way around), the log will always replay to the 
same thing, but it will still be wrong.

In other words, "git bisect" is only as reliable as the data you feed it, 
and if the behavior isn't 100% repeatable and unambiguous (or if you 
simply made a mistake), you need to double-check things.

So after bisecting a commit, if there is any question what-so-ever whether 
the commit makes sense as a result, you need to double-check it. The best 
way to double-check it is to go back to a known-bad state (preferably the 
tip of the branch) and revert the presumed-bad commit, and verify that it 
really fixes the behavior.

But if that is impossible (for example, because the commit no longer 
reverts cleanly), at least make 100% sure that the state at the commit is 
bad, and then go to (all) parents of that commit and make 100% sure that 
the state at those points is _good_. 

IOW, if you've pinpointed 71c11fb57b924c160297ccd9e1761db598d00ac2 as 
being bad, then you should go back and double-check that its parent 
(in this case 4607816f608b42a5379aca97ceed08378804c99f) is good.

Because if it's parent is also bad, then that just means that you made 
some mistake in "git bisect".

The thing about bisecting is that it is _extremely_ efficient. It takes 
essentially the minimal number of answers to get to the end result. But 
that very efficiency also means that getting even just _one_ of those 
answers wrong will take you _way_ off base. There's no room for error, 
because bisect will take each bit and use it to maximally split the error 
space.

In this case, it really sounds like maybe you marked the parent good, even 
though you should have marked it bad.

			Linus