Re: git bisect should return 1 when the first bad commit is found

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> I do think that accessing the bisect/bad ref is a little intimate with
> the implementation (i.e., it implies knowing that there is only a single
> "bad" that we are moving around, unlike "good", where we may mark many
> such tips).

I actually do not think it is merely an implementation detail, but a
rather fundamental part of the "bisect" design.  After all, we are
trying to find *the* single transition point from "the old world" to
"the new world", and the primary assumption that makes "bisection"
work in the first place is that there is only one such transition
point from old to new.  Otherwise, there may be a stretch of history
where one transition from "old" to "new" is followed by another
transition from "new" back to "old" and then again another one from
"old" to "new"; in such a "stripe snake" part of the history, "find
the midpoint, if it is from the new world, then narrow to the world
before that midpoint", which is the central idea of the "bisection"
would not work, would it?

So, ... under that "single transition point" assumption, how would a
"bisect" that uses more than one "bad" would work?  "bad" is the one
that is known to belong to the "new" world that is topologically the
oldest and it moves backward in topology to find the boundary from
the "old" world.  If there were another "bad" (i.e. one that is
known to belong the the "new" world, that may not be the oldest),
shouldn't that have the other one as its ancestor, making it
redundant (i.e. we know we have inherited the badness from the other
one)?

Having said that ...

> So another option is to put the result in a new ref (bisect/result,
> perhaps), but with one twist: delete it at the beginning of a bisection,
> so its presence can be used as a marker that the bisection is complete.

... I kind of like this one exactly for the reasons you give below.

> I.e., you could do "git rev-parse --verify refs/bisect/result" as an
> alternative to "--exit-code". That gives you the added flexibility of
> asking "is the bisection done" separately from "do this next bisection
> step".
>
> -Peff