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@xxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html