On Thu, Jan 13, 2022 at 10:32 AM Ramkumar Ramachandra <r@xxxxxxxxxxxx> 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.
