Re: git bisect bad @

["René Scharfe" <l.s.r@web.de>]

Am 12.01.22 um 19:34 schrieb René Scharfe:
>
> Am 12.01.22 um 18:50 schrieb Junio C Hamano:
>> René Scharfe <l.s.r@web.de> writes:
>>
>>> It would be nice if we could determine if the command was not found by
>>> the shell and halt the bisection.  This is actually indicated by the
>>> shell using error code 127.  However, the script itself could also exit
>>> with that code (e.g. if one of its commands was not found).  Currently
>>> this is interpreted as a bad revision and bisection continues, as
>>> documented in the man page of git bisect.
>>>
>>> If we'd make error code 127 (and 126) special by stopping the bisection
>>> (like we do for 128 and higher) then scripts that relied on that code
>>> indicating a bad revision would require a manual "git bisect bad" at
>>> each affected step.  Annoying, but not dangerous.  Such a script would
>>> have to be modified to convert codes 126 and 127 to e.g. 1.
>>>
>>> Seems like a reasonable trade-off to me.  Thoughts?
>>
>> Probably.  It is safer than the current "all revisions including the
>> bottom one and the top one are bad" which leads to the "merge-base
>> says your good and bad are nonsense" error for the "command not
>> found" case, but what if the one that reports an error with 127 (or
>> 126) is coming from something other than shell (i.e. the 'bisect
>> run' command was fed is not a script at all)?  Is it a no-no for a
>> random binary that is not an implementation of shell to exit with
>> these error status?
>
> The man page of exit(3) mentions the implementation-defined constants
> EXIT_SUCCESS and EXIT_FAILURE from C99.  It also says: "Cooperating
> processes may use other values".
>
> sysexits(3) on BSD mentions a few others, all below 100
> (https://man.openbsd.org/sysexits.3).  Its BUGS section says:
> "The choice of an appropriate exit value is often ambiguous.".
>
> So exit code values are only very vaguely standardized.  It's very
> possible that there are programs that use 126 or 127 to signal
> something other than "can't execute" or "cannot find command".  Under
> the new rules the bisect run script would have to translate them to
> some lower value.

Reserving 126 and 127 shouldn't cause too much trouble, but there's
also a way to avoid it: bisect run could checkout a known-good
revision first and abort if the script returns non-zero for any
reason, including its non-existence.

René