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

[Junio C Hamano <gitster@pobox.com>]

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.

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