On Fri, May 13, 2011 at 2:48 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> When you say that v2.6.38 is good, that means that everything that can >> be reached from 2.6.38 is good. >> >> NOT AT ALL the same thing as "git bisect requires v2.6.38" would be. >> >> The "requires v2.6.38" would basically say that anything that doesn't >> contain v2.6.38 is "off-limits". It's fine to call them "good", but >> that's not the same thing as "git bisect good v2.6.38". >> >> Why? >> >> Think about it. It's the "reachable from v2.6.38" vs "cannot reach >> v2.6.38" difference. That's a HUGE difference. > > Could you please clarify "off-limits"? > > Do you mean "anything before v2.6.38 did not even have this feature, so > the result of testing a version in that range does not give us any > information"? The feature didn't even exist, so a bug can never trigger, > and seeing "good" from such a version does not mean everything reachable > from it is good? Upon seeing "bad" result from a version before v2.6.38, > what can we conclude? The breakage cannot possibly come from the feature > that is being checked, so the procedure to check itself is busted? > In my case, if I'd given bisect a hint that commits that don't include v2.6.38 are unlikely to work for reasons unrelated to the bug, then there should still have been enough revisions left for bisect to tell me "the bug was introduced by the merge of the drm tree but I can't tell you more without testing off-limits revisions". That would have avoided testing three or four revisions that just failed to boot. In my particular case I think it would also have avoided an unnecessary set of tests to figure out why the networking merge broke my system when the networking merge did not, in fact, break my system. This is coincidence -- all of the commits that didn't have the change that fixed the bug the first time around also didn't contain v2.6.38, so I never would have tested them. This is maybe some further justification for a bisect mode that follows the --first-parent path as long as possible -- it might take one or two more kernel builds, but it avoids odd trips around the history that can hit random crap like that. (Of course, it could lead to different random crap, but what can you do?) --Andy --Andy > > -- 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