Am 10.01.22 um 22:04 schrieb Ramkumar Ramachandra: > Hi Junio, > > Junio C Hamano wrote: >> "Ramkumar Ramachandra" <r@xxxxxxxxxxxx> writes: >> >>> # on coq.git, for those curious >>> $ git bisect start >>> $ git bisect bad @ >>> $ git bisect good V8.14.1 >>> $ git bisect run bisect.sh # oops! >>> Lancement de 'bisect.sh' >>> 'bisect.sh': bisect.sh: command not found >>> La base de fusion ea3595845f5013359b2ba4402f948e454350a74c est mauvaise. >>> ... >> >> "command not found"? > > Yeah, I suppose bisect invokes exec(), which then probably expects > the executable to either be in $PATH, or expects me to specify the > path of the executable, failing that; in other words, './bisect.sh'. > In any case, this minor typo shouldn't penalize the user by having to > abort the bisect, and restart it, specifying good and bad commits all > over again. Yes, bisect run invokes the given command using the shell, which tries to find it in $PATH. 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? > Then again, there are other ways to bump your head: what > if I forgot to chmod +x the bisect.sh? That's indicated by error code 126. > What if there is no bisect.sh? You have to provide one, of course, but ... > Should I have to restart the bisect process from the beginning? ... interpreting the non-existence of the script as all revisions being bad seems odd indeed. Halting the bisection at that point makes more sense to me. > 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? Halting the bisection would take the sting out of such a typo, because it's reported immediately and you can fix it and continue. Additionally we could check for the command in the current directory and suggest something like "'bisect.sh' not found; did you mean './bisect.sh'?". René
