Re: Bisects that are neither good nor bad

Re: Bisects that are neither good nor bad

[linux]

(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

Re: Bisects that are neither good nor bad

[Linus Torvalds]

On Mon, 29 May 2006, linux@horizon.com wrote:
> 
> 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

I'm not 100% sure this works - I think it has problems with the ending 
condition because there always ends up being more commits in between when 
the commit space isn't dense, so the "no commits left" thing doesn't 
trigger. But "git bisect visualize" should hopefully help make it obvious

		Linus