Re: git-rev-list: "--bisect" flag

From: Jan Harkes <jaharkes@cs.cmu.edu>
Date: Jun 19, 2005, 03:38 UTC
Message-ID: <20050619033821.GB24982@delft.aura.cs.cmu.edu>
In-Reply-To: <2cfc403205061817181e4d6d5e@mail.gmail.com>

On Sun, Jun 19, 2005 at 10:18:45AM +1000, Jon Seymour wrote:

Show 12 quoted lines

> On 6/18/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > 
> > Ok, I just added a feature to "git-rev-list" that I hereby nominate to be
> > the coolest feature ever, namely the "--bisect" flag, which basically
> > tries to split the list of revisions in two, and prints out just the "most
> > middle" commit.
> > 
> 
> Perhaps in answering this question, you can help me understand the
> intended behaviour of your bisection algorithm a little better. The
> question is this: for your purposes, given a rev-list output, why not
> simply use the literal middle element of the outputed list?

A was known good, parallel development for commits B and C, finally merged into D. A bug got introduced in B, which we discover by the time we have a checked out copy of D.

     .--- B ---.
    /           \
   A             D
    \           /
     `--- C ---'

git-rev-list E ^A shows this as BCD. Pick the halfway point C, and this one checks out ok. So at this point we would decide that the bug got introduced by the C->D change.

My guess is that Linus's bisect algorithm considers the branches, so once C is cleared as good, we get a rev-list that looks like BD, and as such can still find the exact bad commit B.

Jan