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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: May 21, 2025, 13:07 UTC
Message-ID: <01301fa6-eea7-427d-a61f-5cb8dac99afd@gmail.com>
In-Reply-To: <aC2OaeLYJQAOE_S1@pks.im>

On 21/05/2025 09:27, Patrick Steinhardt wrote:

Show 7 quoted lines

> On Tue, May 20, 2025 at 03:34:58PM -0400, D. Ben Knoble wrote:
>> We setup_path() with git_exec_path() unconditionally (8e3462837b (Modify
>> setup_path() to only add git_exec_path() to PATH, 2009-01-18)) when Git
>> starts; as a result, all child processes see Git's exec-path when run,
>> including editors and other programs that don't need it [1]. This can
>> cause confusion for such programs or shells, especially when they rely
>> on finding "git" in PATH to locate other nearby directories,

I'm skeptical that using the location of the git executable to find "git-jump" and "git-completion.zsh" is a good idea. The location of those (and whether they are packaged at all) is entirely at the discretion of whoever packages git - they are not installed by the Makefile and so there is no fixed relationship between their location in the filesystem and the git executable. For instance the example in Ben's blog post looks for "git-jump" at "$prefix/share/git-core/contrib/git-jump" but on my system it is located at "$prefix/share/git/contrib/git-jump"

Show 14 quoted lines

> 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.
> 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. As far as I understand this was a
>      requirement back when people still executed dashed binaries
>      directly. But nowadays scripts don't really do that anymore, but
>      instead use the git binary. And that one doesn't need PATH to be
>      adapted at all, as it knows to listen to GIT_EXEC_PATH and its
>      built-in path anyway.

But don't we still need to change PATH so that hooks, shell aliases, git rebase --exec, git bisect run, etc. still run the same git executable that started them? For example "/usr/bin/git -c alias.g=!git g --version" should report the version of /usr/bin/git, not ~/.local/bin/git which comes first in my PATH if git doesn't change it.

Best Wishes

Phillip