Re: bisect ends with a commit marked good and bad

[Junio C Hamano <junkio@cox.net>]

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?