Re: git bisect bad @
- From
René Scharfe <l.s.r@web.de>
- Date
- Jan 13, 2022, 05:10 UTC
- Message-ID
- <5be4cdad-6769-68e8-0984-5fe89668d007@web.de>
- In-Reply-To
- <13e323e9-eb0c-71c3-215f-b77c91fcc4c8@web.de>
Am 12.01.22 um 19:34 schrieb René Scharfe:
Show 41 quoted lines
> > 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é