Re: git pull on Linux/ACPI release tree

[Linus Torvalds <torvalds@osdl.org>]

On Tue, 10 Jan 2006, Linus Torvalds wrote:
> 
> If a _different_ bug was introduced (even if it had the same effects), 
> yes, you now have two separate bugs. And bisecting two bugs is hard. You 
> need to separate them out some way.

Side note: this is seldom a problem in practice. If it was effectively the 
same bug, just finding the one case that triggered it is sufficient: you 
then know what to look for, and if undoing that one commit isn't enough to 
fix it in the current tree (because the same bug existed in another form 
on another branch), you wouldn't actually start bisecting again. You'd 
start grepping the tree for other cases of that bug.

So the biggest advantage of "git bisect" is _not_ that you can just undo 
the buggy commit. In fact, usually you don't even want to undo it, because 
it probably had a raison-d'etre to begin with. The huge deal about "git 
bisect" is that it pinpoints what caused the bug, and then the fix is 
often something else.

Often it's a "Duh! I fixed one thing, but my fix didn't take Xyz into 
account, so it now broke for another reason" moment.

Most bugs are stupid, in other words.

The _real_ problem with git bisect is when you have a non-technical user 
(common) and there are silly bugs that you know of and already fixed that 
aren't really a problem, but that are show-stoppers for the user who isn't 
a kernel developer (or is, but doesn't know git). They're show-stoppers 
not because we care about them, but because they make the "purely 
mechanical" thing be one where you have to have some manual input.

Another problem (that I've not seen in practice yet, but that I bet _will_ 
be the worst issue) is non-reproducible bugs. They are the nastiest kind 
to debug in the first place, and sadly, "git bisect" simply doesn't help 
you with them. There, nothing but some luck and a lot of thinking and 
testing will help you.

			Linus