Re: git bisect bad @

From: Ramkumar Ramachandra <r@artagnon.com>
Date: Jan 13, 2022, 09:32 UTC
Message-ID: <421215c1-f6ae-4ec2-b666-2a481056ef79@www.fastmail.com>
In-Reply-To: <5be4cdad-6769-68e8-0984-5fe89668d007@web.de>

René Scharfe wrote:

Show 11 quoted lines

> > Am 12.01.22 um 18:50 schrieb Junio C Hamano:
> > 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.

I can't say I'm overly enthusiastic about this trade-off. I think most people would check their bisect scripts against the good revision by hand before starting bisect: why introduce one redundant step for users like me who tend to bump their heads, because they're a bit rusty with machines?

Again, I don't know if this is a good idea, but if exit codes from the shell aren't standardized, surely fork() and exec() would have a better spec? So, perhaps remove the little git-bisect.sh and rewrite it in C? I'd be up for this task, if we decide that this is a better way to go.

Warm regards, Ram