Re: Why can't I use git-bisect to find the first *good* commit?

[Andreas Ericsson <ae@op5.se>]

On 03/28/2011 11:32 AM, Ævar Arnfjörð Bjarmason wrote:
> Something was broken a 100 revisions ago, has now been fixed, but I
> want to find when it was fixed.
> 
> I'd expect this to work:
> 
>      $ git bisect start
>      $ git bisect good
>      $ git bisect bad HEAD~100
>      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?
> 
> But instead I have to do:
> 
>      $ git bisect start
>      $ git bisect bad
>      $ git bisect good HEAD~100
> 
> And then proceed to mark good revisions as bad, and bad revisions as
> good.
> 
> That works, but it's very confusing.
> 
> Why can't bisect just do the right thing here and accept that your
> more recent revesion is the good one, and the old one is the bad one?

It's due to the fact that bisect is, in 99% of the cases, used to
locate the commit that introduced a bug and the implementation details
naturally gear towards that scenario, with fixed names that do the
Right Thing(tm) in 99% of all cases.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.