Hmm, this all makes sense as to why it's happening, thank you. In my
case the ` /usr/local/Cellar/git/2.3.5/libexec/git-core` (git
--exec-path) does give all the proper binaries and sub-binaries. It
shows up twice because the GIT_EXEC_PATH environment variable is used
too (which is the same in my case since it hasn't been overriden).
The /usr/local/bin therefore comes from **the path to the running
"git" itself**.
There still seems to be a potential issue I can't figure out how to
work around with this. If **the path to the running "git" itself** is
in /usr/local/bin or some other common area, then that would still
always get prepended prior to external PATH -- which means **other**
external programs will inherit precedence overriding the system PATH
preferences.
For example, in our case, many scripts run in our specific Python
environment, which ala virtualenv is located in a user-specific path
(e.g. ~/.virtualenv/foo/bin/python), which appears earlier in the user
PATH so it affects all shell processes using `#!/usr/bin/env python`.
When a git-exec prepends /usr/local/bin, the system installed Python
is used instead.
There are other use cases I can think of that would cause this issue
as well -- user provides more recent version of "bazfoo" program in
~/bin which they prepend of their system PATH, git-exec then prepends
shared path of a system binary directory which also contains older
version of bazfoo, older version then gets used instead.
So, I guess what I'm looking for is:
- A way to prevent the **path to the running "git" itself** portion
of setup_path from firing, (OR)
- A way to specify (via env var?) paths that must remain in high
precedence even during a git-exec, e.g.:
NEWPATH = [git --exec-path] : [GIT_EXEC_PATH] :
[$PROPOSED_HIGH_PRECENDENCE_PATH] : ['git itself' path] : [$PATH] (OR)
- A way to refine git-exec default behavior to avoid this edge case
(my C is a little rusty but I'm happy to try to help out if we can
think of a good logic), (OR)
- Something else clever I am not aware of.
Thanks so much for your assistance.
On Tue, Apr 14, 2015 at 1:17 PM, Junio C Hamano <[email protected]> wrote:
> Matthew Rothenberg <[email protected]> writes:
>
>> - what is the expected PATH modification behavior for subprocesses of
>> git-hooks? Is this documented anywhere?
>> - what would be causing /usr/local/bin to be prepended here, and can
>> it be adjusted via preference?
>
> This is not limited to hooks and very much deliberate, I think. In
> order to make sure anything that is called from "git" wrapper gets
> picked up from GIT_EXEC_PATH so that the matching version of the git
> subprogram is used, "git <cmd>" does this before running "git-<cmd>"
> (in git.c):
>
> /*
> * We use PATH to find git commands, but we prepend some higher
> * precedence paths: the "--exec-path" option, the GIT_EXEC_PATH
> * environment, and the $(gitexecdir) from the Makefile at build
> * time.
> */
> setup_path();
>
> And setup_path() is defined in exec_cmd.c to start the new PATH with
> git-exec-path, and then the path to the running "git" itself, and
> then finally the external PATH.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
