Re: git bisect bad @

[Christian Couder <christian.couder@gmail.com>]

On Thu, Jan 13, 2022 at 10:32 AM Ramkumar Ramachandra <r@artagnon.com> wrote:
>
> René Scharfe wrote:

> > Reserving 126 and 127 shouldn't cause too much trouble,

I don't think it's a good idea at this point to reserve the 126 and
127 error codes as there might be existing scripts relying on them to
mean "bad".

Perhaps we could introduce a new command line option, for example
--bad-is-only-1, to specify that the only error code considered bad
will be 1. Or perhaps a more general --bad-is=<list of ranges>, to be
able to specify all the values and ranges that should be considered
bad.

> > 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?

I also don't like introducing a redundant step, unless a special
command line option is introduced for it.

> 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.

There has been a lot of effort, especially by Miriam (added in Cc), to
port git-bisect.sh to C over the years.