summaryrefslogtreecommitdiff
path: root/t/t5802-connect-helper.sh
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2015-04-22 14:14:02 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2015-04-22 13:41:31 -0700
commita0b4507ef72027052668c11b49f71bed89bcb293 (patch)
treefb4013f20c13ed68a5ecddb6f5f43c62d5249344 /t/t5802-connect-helper.sh
parentGit 2.2.2 (diff)
downloadtgif-a0b4507ef72027052668c11b49f71bed89bcb293.tar.xz
stop putting argv[0] dirname at front of PATH
When the "git" wrapper is invoked, we prepend the baked-in exec-path to our PATH, so that any sub-processes we exec will all find the git-foo commands that match the wrapper version. If you invoke git with an absolute path, like: /usr/bin/git foo we also prepend "/usr/bin" to the PATH. This was added long ago by by 231af83 (Teach the "git" command to handle some commands internally, 2006-02-26), with the intent that things would just work if you did something like: cd /opt tar xzf premade-git-package.tar.gz alias git=/opt/git/bin/git as we would then find all of the related external commands in /opt/git/bin. I.e., it made git runtime-relocatable, since at the time of 231af83, we installed all of the git commands into $(bindir). But these days, that is not enough. Since f28ac70 (Move all dashed-form commands to libexecdir, 2007-11-28), we do not put commands into $(bindir), and you actually need to convert "/usr/bin" into "/usr/libexec". And not just for finding binaries; we want to find $(sharedir), etc, the same way. The RUNTIME_PREFIX build knob does this the right way, by assuming a sane hierarchy rooted at "$prefix" when we run "$prefix/bin/git", and inferring "$prefix/libexec/git-core", etc. So this feature (prepending the argv[0] dirname to the PATH) is broken for providing a runtime prefix, and has been for many years. Does it do anything for other cases? For the "git" wrapper itself, as well as any commands shipped by "git", the answer is no. Those are already in git's exec-path, which is consulted first. For third-party commands which you've dropped into the same directory, it does include them. So if you do cd /opt tar xzf git-built-specifically-for-opt-git.tar.gz cp third-party/git-foo /opt/git/bin/git-foo alias git=/opt/git/bin/git it does mean that we will find the third-party "git-foo", even if you do not put /opt/git/bin into your $PATH. But the flipside of this is that we will bump the precedence of _other_ third-party tools that happen to be in the same directory as git. For example, consider this setup: 1. Git is installed by the system in /usr/bin. There are other system utilities in /usr/bin. E.g., a system "vi". 2. The user installs tools they prefer in /usr/local/bin. E.g., vim with a "vi" symlink. They set their PATH to /usr/local/bin:/usr/bin to prefer their custom tools. 3. Running /usr/bin/git puts "/usr/bin" at the front of their PATH. When git invokes the editor on behalf of the user, they get the system vi, not their normal vim. There are other variants of this, including overriding system ruby and python (which is quite common using tools like "rvm" and "virtualenv", which use relocatable hierarchies and $PATH settings to get a consistent environment). Given that the main motivation for git placing the argv[0] dirname into the PATH has been broken for years, that the remaining cases are obscure and unlikely (and easily fixed by the user just setting up their $PATH sanely), and that the behavior is hurting real, reasonably common use cases, it's not worth continuing to do so. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5802-connect-helper.sh')
0 files changed, 0 insertions, 0 deletions