(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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
