# Is this a git-bisect bug? 4 messages from 2009-02-21 to 2009-02-22. Participants: walt, Teemu Likonen, Christian Couder. Thread: https://gitlist.dev/t/17939 ## walt, 2009-02-21 17:07 Subject: Is this a git-bisect bug? Message-ID: URL: https://gitlist.dev/e/gnpccl%24l69%241%40ger.gmane.org ``` 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, 2009-02-21 17:25 Subject: Re: Is this a git-bisect bug? Message-ID: <87skm7em72.fsf@iki.fi> URL: https://gitlist.dev/e/87skm7em72.fsf%40iki.fi In-Reply-To: ``` 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 | * 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, 2009-02-21 20:56 Subject: Re: Is this a git-bisect bug? Message-ID: URL: https://gitlist.dev/e/gnppph%24r8r%241%40ger.gmane.org In-Reply-To: <87skm7em72.fsf@iki.fi> ``` 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. Thanks. ``` ## Christian Couder, 2009-02-22 06:47 Subject: Re: Is this a git-bisect bug? Message-ID: <200902220747.29932.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/200902220747.29932.chriscool%40tuxfamily.org In-Reply-To: ``` Le samedi 21 février 2009, walt a écrit : > 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. ```