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
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
