Error message with 'bisect'
chase.douglas at canonical.com
Mon Jul 12 14:34:44 BST 2010
On Sun, 2010-07-11 at 23:58 -0400, Nicolas Pitre wrote:
> On Fri, 9 Jul 2010, Mathieu Poirier wrote:
> > Andy,
> > I started investigating the "bisect" command as you suggested on Friday.
> > After having a few successful runs with the tool, I isolated my problem
> > to a check in between rc3 and rc4... But there is 425 of them.
> > So what better tool than "bisect" to sort through all this ! I checkout
> > a fresh upstream tree and set out to bisect but got an error message:
> > mpoirier at black:~/canonical/linus$ git bisect start
> > mpoirier at black:~/canonical/linus$ git bisect good v2.6.35-rc4
> > mpoirier at black:~/canonical/linus$ git bisect bad v2.6.35-rc3
> > Some good revs are not ancestor of the bad rev.
> > git bisect cannot work properly in this case.
> > Maybe you mistake good and bad revs?
> > mpoirier at black:~/canonical/linus$
> > Tim tried on his own tree and got the same issue. Would you know what
> > is going on ?
> The 'git bisect' command is meant to let you find when a bug was
> _introduced_, and not when it was _fixed_. What the message above is
> telling you is that the good revision you provided (v2.6.35-rc4) is not
> an ancestor of the bad revision (v2.6.35-rc3). Obviously, v2.6.35-rc4
> cannot have happened before v2.6.35-rc3.
> If what you really want is to find out when a bug was fixed then you can
> use 'git bisect' as well, but then you need to invert all the logic,
> i.e. mark fixed commits as "bad" and non fixed ones as "good". In any
> case, the "good" commits are expected to exist before the "bad" ones.
How sure are you that this is the case? I thought I had used git bisect
in the reverse way before and things just worked.
More information about the kernel-team