On Fri, May 13, 2011 at 12:11 PM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, May 13, 2011 at 7:56 AM, Andrew Lutomirski <luto@xxxxxxx> wrote: >> >> So what I really want is a fancy version of git bisect that makes no >> assumptions about the relationship of good and bad commits in the >> graph and just finds me a commit that is bad but for which all parents >> are good or vice versa. > > Ehh. That's the "non-fancy" way of testing, I'm afraid: if you cannot > make assumption about the relationship between good and bad commits, > then you have to test _every_ commit. > > So yes, bisection has its problems. But they really do come from the > fact that it's very efficient. When you have (on average) about ten > thousand commits between releases, you have to make assumptions about > the relationships. But once you do that, the efficiency also results > in a certain fragility. > > Think of it as a compression method: it generates the smallest > possible set of test points for you. But it's a "lossy" compression - > you don't test everything. And it's extreme: it boils down 10k commit > events to about 13 bisection events. If anything goes wrong (like the > bug not being entirely repeatable, or the bug comes and goes), it will > give the wrong answer. > > The good news is that _usually_ it works really well. And when the > choice is between "works really well for 10k commits but can have > problems" and "you need to test all 10k commits", the "can have > problems" part turns out to be a pretty small downside ;) In conclusion, I found the problem. It's a clusterfuck and I think there's no way that any bisection tool under any sane assumptions could have found it. Patch coming in a couple seconds b/c I think it needs to go in to 2.6.39. --Andy > > Linus > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html