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

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2019, 18:41 UTC
Message-ID: <xmqqo92mhlla.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20190623224935.GD1100@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 18 quoted lines

> On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
>
>> Thanks for your answer.
>> 
>> I was expecting the HEAD to point to the first bad commit.
>> 
>> In mercurial, the exit status tells you information about the
>> bisection process:  https://www.mercurial-scm.org/repo/hg/help/bisect
>> 
>> Sure one can parse stdout, it's just more tedious than just checking
>> the return code and having the HEAD left to the original bad commit.
>
> 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.