Re: git bisect bad @

From: Christian Couder <christian.couder@gmail.com>
Date: Jan 13, 2022, 12:28 UTC
Message-ID: <CAP8UFD3tyBhrOQzg9j4qDAT0Tb8TCTK0=J6ORsiLVuMWn+W9wg@mail.gmail.com>
In-Reply-To: <421215c1-f6ae-4ec2-b666-2a481056ef79@www.fastmail.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.

Show 10 quoted lines

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

Show 5 quoted lines

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