Re: Is this a git-bisect bug?

From: walt <w41ter@gmail.com>
Date: Feb 21, 2009, 20:56 UTC
Message-ID: <gnppph$r8r$1@ger.gmane.org>
In-Reply-To: <87skm7em72.fsf@iki.fi>

Teemu Likonen wrote:

Show 25 quoted lines

> On 2009-02-21 09:07 (-0800), walt wrote:
>
>> I'm using the current git.git to bisect a bug in Linus.git.
>>
>> I got this far and then ran into trouble:
>> good 2.6.29-rc5-00094-gc951aa6
>> bad  2.6.29-rc5-00112-g3501033
>>
>> A glance at git log will show that those two commits were
>> both from Feb 17 with only one other commit between them.
>>
>> So, why does this happen?:
>>
>> $git bisect start 3501033 c951aa6
>> Bisecting: 8 revisions left to test after this
>> be716615fe596ee117292dc615e95f707fb67fd1] x86, vm86: fix preemption bug
>
> Someone will probably give real explanation but non-linear development
> is part of it:
>
> $ git log --graph --pretty=oneline --abbrev-commit c951aa6..3501033
>
> *   3501033 Merge branch 'x86-fixes-for-linus' of git:// [...]
> |\
> | * be71661 x86, vm86: fix preemption bug

 > ...

I see now that git bisect actually found the guilty commit for me, but completely confused me by turning out five kernels in a row with the names 2.6.29-rc3-00nnn while I was bisecting an rc5 kernel. I stopped because of those tag names when I should have just forged ahead.

I would be interested to hear opinions on whether that rc3 tag is the correct one to use for the bisected kernels.

Thanks.