Re: git bisect bad @

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

Am 10.01.22 um 22:04 schrieb Ramkumar Ramachandra:
> Hi Junio,
>
> Junio C Hamano wrote:
>> "Ramkumar Ramachandra" <r@artagnon.com> 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é