{"thread":{"id":"4346","subject":"Re: Bisects that are neither good nor bad","startedAt":"2006-05-29T22:56:32Z","lastAt":"2006-05-30T00:46:32Z","messageCount":2,"participants":["linux@horizon.com","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"20935","messageId":"20060529225632.7073.qmail@science.horizon.com","threadId":"4346","inReplyTo":null,"subject":"Re: Bisects that are neither good nor bad","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2006-05-29T22:56:32Z","receivedAt":"2006-05-29T22:56:32Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"(Cc: to the git list, since the people there undoubtedly know much better.)\n\n> Is there a method of bisecting that means neither \"good\" nor \"bad\"?  I\n> have run into kernel problems that are not related to the problem I'm\n> attempting to track.  Some are not avoidable by changing the .config (see\n> the third bisect in comments 10 and 11 in the bugzilla report).\n\nYes.  While you're bisecting, HEAD is a special \"bisect\" head used just\nfor that purpose.  If you encounter a compile error or are otherwise\nunable to test a version, you can \"git reset --hard <commit>\" to jump\nto some other commit and test that instead.  Because that command\nunconditionally changes both the current head and the checked-out code,\nit's normally somewhat dangerous, but while bisecting, there's no problem.\nYou can choose anything you like to test instead of git-bisect's suggested\nversion, but staying near the middle of the uncertain range is usually\na good idea.  \"HEAD^\" (the parent of the current commit) is often a\nsimple choice.  \"git bisect visualize\" might give you some ideas.\n\nNote that if the problem actually is in the area of the untestable commit,\ngit bisect might drag you back there, but this lets you try to avoid it.\n\nIt's also worth repeating some advice from the manual:\n\n>> You can further cut down the number of trials if you know what part of\n>> the tree is involved in the problem you are tracking down, by giving\n>> paths parameters when you say bisect start, like this:\n>>\n>> $ git bisect start arch/i386 include/asm-i386\n"},{"id":"20943","messageId":"Pine.LNX.4.64.0605291744390.5623@g5.osdl.org","threadId":"4346","inReplyTo":"20060529225632.7073.qmail@science.horizon.com","subject":"Re: Bisects that are neither good nor bad","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-05-30T00:46:32Z","receivedAt":"2006-05-30T00:46:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 29 May 2006, linux@horizon.com wrote:\n> \n> It's also worth repeating some advice from the manual:\n> \n> >> You can further cut down the number of trials if you know what part of\n> >> the tree is involved in the problem you are tracking down, by giving\n> >> paths parameters when you say bisect start, like this:\n> >>\n> >> $ git bisect start arch/i386 include/asm-i386\n\nI'm not 100% sure this works - I think it has problems with the ending \ncondition because there always ends up being more commits in between when \nthe commit space isn't dense, so the \"no commits left\" thing doesn't \ntrigger. But \"git bisect visualize\" should hopefully help make it obvious\n\n\t\tLinus\n"}]}