Re: Is this a git-bisect bug?

[Christian Couder <chriscool@tuxfamily.org>]

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.