Re: [RFC] Proposal: New options for git bisect run to control the interpretation of exit codes

From: Philip Oakley <philipoakley@iee.email>
Date: Mar 28, 2020, 19:14 UTC
Message-ID: <24c58c80-c274-6a64-051c-90329432b85d@iee.email>
In-Reply-To: <CAD_xR9cC_MrrqGoHuBsfuVAQ=qVMd0rjXvp22+8ed-D=4TQRbA@mail.gmail.com>

Sorry this is late. On 16/01/2020 02:40, Stephen Oberholtzer wrote:

Show 22 quoted lines

>> The above doesn't tell what happens if a status is both on the
>> --old-status and on the --new-status lists...
> No, the below does.
>
>>>  * Otherwise, the command is treated as having experienced a fatal error,
>>>    and run will terminate with a nonzero exit status.
>> ...so it seems that it is an error only when such a status code is
>> actually received by `git bisect run`.
>>
>> Some people could argue though that `--new-status=0 --old-status=0`
>> should be detected as an error as soon as `git bisect run` is
>> launched.
> There are a few reasons for not raising an error immediately:
> - Such a check would not be free.  While the example you gave is
> simple enough, things can quickly get complicated.  A generalized
> version would have to check every single status from 0 to 255
>   (that said, I can see some value in proactively checking 0 and 1
> before starting the run, just as a sanity check)
> -  If there _is_ an ambiguous exit code, it doesn't actually matter
> unless it's actually encountered
> - If the user makes such a mistake, the bisection doesn't go off the
> rails; it just halts.

Will such a mistake be _reported_ (suitable message) to the user? This would at least short circuit misunderstandings as to the reason for the halting of the bisect.

> A simple 'git bisect good' or 'git bisect bad',
> followed by another call to "run" with corrected options, will address
> the issue.
>

Philip