Re: bisect ends with a commit marked good and bad

From: Junio C Hamano <junkio@cox.net>
Date: Feb 15, 2006, 08:01 UTC
Message-ID: <7vpslpm4oy.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <E1F9Gwm-0001Dy-3b@approximate.corpus.cam.ac.uk>

Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:

> How would I use gitk to show the those three good and three bad commits,
> and their spanning tree?  Neither the man entry nor the examples of its
> use in git-bisect taught me enough to use it properly.

The way bisect narrows down bug hunting is to find a single regression. IOW, the only question you can ask bisect is "this older one was known to be good, but somehow this new one is bad. If it was caused by one bug introduced somewhere during the course of changes between the two, which one is it?"

So you always start by giving one good and one bad (or one bad and one good, the order does not matter). That leaves * as suspects.

    o---o---O---*---*---*---*---X---o
         \             /
          *---*---*---*

        O (good) X (bad)

Since it is finding a single regression, o commits are irrelevant. commits after bad one X may have fixed the bug but you are not interested in it. Commits before good one O might have been broken in some other way, but we are looking for a single regression, so they do not really matter either.

Then bisect suggests you one of (*) commits. Not at random, but somewhere midway.

    o---o---O---*---*---*---*---X---o
         \             /
          *---*---*---?

        O (good) X (bad)

If ? is good, then three * suspects are good so you then have to worry about remaining four * between the first O and X. That's how you narrow things down.

You say a2d823bf is bad and 0f442aa2 is good. However, the a2d823bf is a proper ancestor of 0f442aa2. That is, earlier it was good but now it is good. As if you are trying to locate the commit that fixed the bug. This is an impossible situation for the bisect.

So your initial input may be truly good and bad commits, but there might be more than one regression involved.

To look at the graph, you could do something like this:

for r in $good; do git tag good-$r $(git-rev-parse --verify $r); done for r in $bad; do git tag bad-$r $(git-rev-parse --verify $r); done gitk $(git-rev-parse $good) $(git-rev-parse --not $bad)

You will notice there is only one bad-* way below all the good-* ones. Another possibility is maybe you have your good and bad swapped?