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

[Jeff King <peff@peff.net>]

On Mon, Jun 24, 2019 at 11:41:53AM -0700, Junio C Hamano wrote:

> > I think it might be nice for Git to write a well-known refname (like
> > BISECT_RESULT or similar) so that you can refer to that instead of
> > having to read stdout (whether by machine or by a user
> > cutting-and-pasting). And I cannot offhand think of a particular reason
> > why that could not just be HEAD (instead of something bisect-specific)
> > after the bisect finishes.
> 
> As Christian downthread reminds us, that is what the bisect/bad ref
> is (which I totally forgot when I gave the earlier response).  I do
> not think we need a new ref, but I do not think it is so bad to add
> an option "git bisect --exit-code ( --good | --bad ) [<commit-ish>]"
> that makes the command usually exit with non-zero status.  Unless we
> have found the final answer successfully, that is, and in that case
> the command would exit with 0 status to signall "all done".
> 
> But that should be an option.

Ah, right, I forgot that we already have such a ref. So that does seem
like a reasonable way to access it (and as Christian notes, it's
documented as well).  And I agree with you that any exit-code magic
should require the user to ask for it explicitly.

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).

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.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