threads / bug / 17939

Is this a git-bisect bug?

Subject: Is this a git-bisect bug?

## tl;dr

4 messages between Feb 21, 2009 and Feb 22, 2009.

replies: 3people: 3as markdown or json

walt· Feb 21, 2009, 17:07 UTC · lore
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

git log shows that commit is from Jan 13, way back in 2.6.29-rc3. Can anyone reproduce/explain this?

Thanks!
Teemu Likonen· Feb 21, 2009, 17:25 UTC · re: walt · lore

Re: Is this a git-bisect bug?

On 2009-02-21 09:07 (-0800), walt wrote:
Show 14 quoted lines
> 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
| * e49590b x86, olpc: fix model detection without OFW
| * b13e246 x86, hpet: fix for LS21 + HPET = boot hang
| * 7ad9de6 x86: CPA avoid repeated lazy mmu flush
| * 34b0900 x86: warn if arch_flush_lazy_mmu_cpu is called in [...]
| * d85cf93 x86/paravirt: make arch_flush_lazy_mmu/cpu disable [...]
| * be03d9e x86, pat: fix warn_on_once() while mapping 0-1MB range [...]
| * 4f06b04 x86/cpa: make sure cpa is safe to call in lazy mmu mode
| * 9f339e7 x86, ptrace, mm: fix double-free on race
*   8ce9a75 Merge branch 'core-fixes-for-linus' of git:// [...]
|\  
| * 9af8814 iommu: fix Intel IOMMU write-buffer flushing
| * 2fff78c futex: fix reference leak
* b30b774 Merge branch 'merge' of git://git.kernel.org/pub/scm/ [...]
* 26456dc powerpc/vsx: Fix VSX alignment handler for regs 32-63
* 0047656 powerpc/ps3: Move ps3_mm_add_memory to device_initcall
* 06eccea powerpc/mm: Fix numa reserve bootmem page selection
* fbc78b0 powerpc/mm: Fix _PAGE_CHG_MASK to protect _PAGE_SPECIAL
walt· Feb 21, 2009, 20:56 UTC · re: Teemu Likonen · lore

Re: Is this a git-bisect bug?

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.
Christian Couder· Feb 22, 2009, 06:47 UTC · re: walt · lore

Re: Is this a git-bisect bug?

Le samedi 21 février 2009, walt a écrit :
Show 38 quoted lines
> Teemu Likonen wrote:
> > 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.
Please have a look at this:
http://thread.gmane.org/gmane.comp.version-control.git/99967/focus=99977

Regards, Christian.

← back to recent threads