Re: git bisect bad @

From: Ramkumar Ramachandra <r@artagnon.com>
Date: Jan 13, 2022, 15:16 UTC
Message-ID: <925ef53d-c8b2-4ef4-acee-490900e8a3b7@www.fastmail.com>
In-Reply-To: <8bc73981-589e-20e5-247b-2f74e166ae1a@web.de>

René Scharfe wrote:

Show 6 quoted lines

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

Show 5 quoted lines

> 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