Re: Who broke cb8f488c33 patch? (was Re: [PATCH 1/1] USBHID: correct start/stop cycle)

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

On Thu, 13 Nov 2008, Helge Deller wrote:
> 
> I bisected twice. Both times I found this one to be the culprit.
> Nevertheless, just reverting this (Thanks Denys!) didn't fixed the USB
> problem.

The trivial bisecting approach doesn't work if there are two independent 
bugs that have overlapping lifetimes. In fact, bisection doesn't 
necessarily work even if the lifetimes of the bugs are clearly disjoint, 
because then if you look for bug A, but mark something "bad" because of 
bug B, it can easily end up zeroing in on the wrong cause.

So "git bisect" is an absolutely wonderful tool, but it does require you 
to be able to be sure about _which_ exact bug you chase down to give 
reliable answers.

In the presense of multiple bugs, you have two choices:

 (a) either you have to know how to distinguish them reliably in order to 
     give a clean good/bad for the particular bug you are chasing.

     This can be impossible: one bug may make it impossible to even _test_ 
     for the other bug, eg a bug that prevents bootup will obviously make 
     it impossible to see whether an independent run-time bug exists or 
     not. In this case, you have to do (b)

 (b) Find _one_ bug first (doesn't matter which), and fix it. And then, do 
     a second bisection run, but before each test, you may need to apply 
     the fix for the first bug, so that you know that's not the an issue.

     This can be automated (check if the broken commit is in the current 
     tree to be tested, apply a patch to fix it if it is), but it's not as 
     simple as just saying "let's bisect".

So bisection with multiple bugs is certainly possible, but it's also 
unquestionably a lot more work, and more complicated.

			Linus