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

[Philip Oakley <philipoakley@iee.email>]

Sorry this is late.
On 16/01/2020 02:40, Stephen Oberholtzer wrote:
>> 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