Re: PATH modifications for git-hook processes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <gitster@xxxxxxxxx> wrote:
> Matthew Rothenberg <mroth@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]