Re: Why can't I use git-bisect to find the first *good* commit?
- From
Andreas Ericsson <ae@op5.se>
- Date
- Mar 28, 2011, 10:39 UTC
- Message-ID
- <4D906549.9050102@op5.se>
- In-Reply-To
- <AANLkTinQ0rCw2ydisHra779r6_iSOxqRwOStpJrNbx7h@mail.gmail.com>
On 03/28/2011 11:32 AM, Ævar Arnfjörð Bjarmason wrote:
Show 25 quoted lines
> 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.