Bisects that are neither good nor bad

(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
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html

On Mon, 29 May 2006, linuxhorizon.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
-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html