Re: [PATCH 4/4] drop git_exec_path() from non-Git commands' PATH

From: Junio C Hamano <gitster@pobox.com>
Date: May 21, 2025, 14:47 UTC
Message-ID: <xmqq1psidnqc.fsf@gitster.g>
In-Reply-To: <aC2OaeLYJQAOE_S1@pks.im>

Patrick Steinhardt <ps@pks.im> writes:

> I agree with what Junio mentioned in a parallel thread, especially
> around Git hooks. The expectation there is that those may execute other
> Git commands, and that should typically be using the same execution
> environment as the original Git command that has been invoking the hook.

If by "Giving the same execution environment as the original" you meant "not just git-subcmd from anywhere, but from the same place", you are right.

The point of GIT_EXEC_PATH is to allow users to tell 'git' that when they say 'git foo', they mean the specific version of 'foo' found at $GIT_EXEC_PATH/git-foo, not at $(git --exec-path)/git-foo that may be different; otherwise they wouldn't be passing GIT_EXEC_PATH in the first place.

In other words, "These days nobody runs git-foo anymore" may be a correct statement, but as an argument to draw the conclusion "hence we should ignore GIT_EXEC_PATH", it is an argument that entirely misses the point.

Show 5 quoted lines

> So refining this patch so that the mechanism is opt-in probably makes
> sense.
>
>     A slight tangent: I wonder whether it is even required nowadays to
>     adapt PATH at all anymore.

Meaning we include GIT_EXEC_PATH to PATH? When a running "git" invokes a subcommand "foo" that is not built-in, it runs "git-foo" but doesn't it do so by following the PATH (with the expectation that GIT_EXEC_PATH has already been taken into account, with setup_path() in exec-cmd.c, to include it in PATH)?

So, as long as you subscribe to "the same execution environment" like you said above, I do not think you can avoid the setup_path() call early in git.c::cmd_main().