Patrick Steinhardt <ps@xxxxxx> 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. > 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().
