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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



That's a really good point! Perhaps we should have a --invert flag?
Sent from my BlackBerry device on the Rogers Wireless Network

-----Original Message-----
From: Ãvar ArnfjÃrà Bjarmason <avarab@xxxxxxxxx>
Sender: git-owner@xxxxxxxxxxxxxxx
Date: Mon, 28 Mar 2011 11:32:21 
To: Git Mailing List<git@xxxxxxxxxxxxxxx>
Subject: Why can't I use git-bisect to find the first *good* commit?

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?
--
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
ÿô.nlj·Ÿ®‰­†+%ŠË±é¥Šwÿº{.nlj· ŠßžØn‡r¡öë¨è&£ûz¹Þúzf£¢·hšˆ§~†­†Ûÿÿïÿ‘ê_èæ+v‰¨þ)ßø

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]