Re: git bisect bad @

["Ramkumar Ramachandra" <r@artagnon.com>]

René Scharfe wrote:
> Am 13.01.22 um 13:28 schrieb Christian Couder:
> > 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".
> 
> Certainly possible -- people get the weirdest ideas.

My gut reaction is that this is an overly conservative point of view. There are two factors to consider: first, bisect scripts are usually short one-time throwaway scripts tailored to one project for one problem. Second, how likely is it that these people that have a complex script with 126/127 as the exit code, which they have been using for years to run bisect on the same project for the same problem, update their version of git frequently?

Again, I might be wrong, because I don't know how people use bisect. Worst case, we can display a warning about this backward incompatibility in the next few versions.

> The implementation language of git bisect is not immediately relevant
> here, but that the shell is used to call the user-supplied bisect run
> script is.  If we'd run it directly (without RUN_USING_SHELL) we could
> distinguish error code 126/127 from execution errors.  I assume the
> option is used to stay compatible with the old shell version of bisect.

Sorry, my misunderstanding. I thought the external command was being called from git-bisect.sh. I don't think I understand the purpose of RUN_USING_SHELL (it just seems to put an "sh -c" in the beginning):

	static const char **prepare_shell_cmd(struct strvec *out, const char **argv)
	{
        ...
			strvec_push(out, "sh");
			strvec_push(out, "-c");

			if (!argv[1])
				strvec_push(out, argv[0]);
			else
				strvec_pushf(out, "%s \"$@\"", argv[0]);
       ...
	}

Warm regards,
Ram