(Cc: to the git list, since the people there undoubtedly know much better.) > Is there a method of bisecting that means neither "good" nor "bad"? I > have run into kernel problems that are not related to the problem I'm > attempting to track. Some are not avoidable by changing the .config (see > the third bisect in comments 10 and 11 in the bugzilla report). Yes. While you're bisecting, HEAD is a special "bisect" head used just for that purpose. If you encounter a compile error or are otherwise unable to test a version, you can "git reset --hard <commit>" to jump to some other commit and test that instead. Because that command unconditionally changes both the current head and the checked-out code, it's normally somewhat dangerous, but while bisecting, there's no problem. You can choose anything you like to test instead of git-bisect's suggested version, but staying near the middle of the uncertain range is usually a good idea. "HEAD^" (the parent of the current commit) is often a simple choice. "git bisect visualize" might give you some ideas. Note that if the problem actually is in the area of the untestable commit, git bisect might drag you back there, but this lets you try to avoid it. It's also worth repeating some advice from the manual: >> You can further cut down the number of trials if you know what part of >> the tree is involved in the problem you are tracking down, by giving >> paths parameters when you say bisect start, like this: >> >> $ git bisect start arch/i386 include/asm-i386 - : 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