http://bugzilla.kernel.org/show_bug.cgi?id=14354 --- Comment #157 from Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 2009-10-30 18:05:28 --- On Fri, 30 Oct 2009, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > > Well I've been doing bisects but I'm getting skeptical of the results; > either my testcase isn't reliable enough or all the merges are confusing > git-bisect (?) Anyway it keeps ending up on nonsensical commits. Merges don't confuse git-bisect (lots of merges may make bisection slightly less _efficient_, though, because it can be impossible to find commits that are nicely "in the middle"), but the way bisection works, even a _single_ wrong "git bisect good/bad" statement can - and will - make bisection results go off totally in the weeds. Bisection is designed to be efficient, which is absolutely wonderful when you have a 100% unambiguous bug that needs to be found in 10,000 commits. It's what gives us that nice log2() behavior. But the downside of that efficiency is the same as the downside of any very efficient data compression with no checksum: there is absolutely zero redundancy. So then if even just a single bit of information (in this case the "good/bad" info) is wrong, the end result will not just be wrong - it will be _disastrously_ wrong, and you won't even be anywhere _close_ to the correct end result. [ In fact, the way bisection works, if you give a single incorrect bisection point, the end result will usually be close to the commit you incorrectly marked, rather than the actual buggy commit you searched for. That _can_ be used as a hint when you're unsure - when getting a clearly bogus bisection result, you can look at the bisect log, and try to find the first commit in the log that is close to the clearly bogus result, and you might decide to re-test that commit more carefully. And then if, on re-testing, it turns out that you had been wrong the first time, you might be able to avoid re-doing the whole bisection thing, and instead re-do the log up to the incorrect - and now fixed - entry, and continue from there. ] That said, if you end up being uncertain about the bisection points, and can't give more than a "95% confidence", bisection will almost inevitably fail. A bug that is timing-dependent can be almost impossible to bisect. Even if you can reliably trigger it _eventually_, you may have to test so long at each bisection point that bisection becomes practically useless. Linus -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
