René Scharfe <l.s.r@xxxxxx> 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? >> This presents another possible opportunity for enhancement: in an >> overwhelmingly large majority of the use cases (or so I assume), './' >> is really redundant. > Adding the current directory to $PATH would be inconsistent and might > even be dangerous. > > Prepending "./" to a given command that contains no directory separator > is speculative -- what if that command is actually found in $PATH? Bad idea. > Additionally we could check for the command in the current directory > and suggest something like "'bisect.sh' not found; did you mean > './bisect.sh'?". It may not hurt but I do not think it is necessary at all, as long as the "halt the 'bisect run' session upon 126 and 127"
