Error message with 'bisect'

[Chase Douglas]

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.

-- Chase