{"thread":{"id":"39073","subject":"PATH modifications for git-hook processes","startedAt":"2015-04-14T16:04:25Z","lastAt":"2015-04-22T20:00:19Z","messageCount":12,"participants":["Matthew Rothenberg","Junio C Hamano","Jeff King","David Rodríguez","Eric Sunshine","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"259353","messageId":"CAKuTQSGEmHHr-c+Tc2jM-JPkx6+_f3gp8Zjj8EuQy_e4=PvMzg@mail.gmail.com","threadId":"39073","inReplyTo":null,"subject":"PATH modifications for git-hook processes","fromName":"Matthew Rothenberg","fromEmail":"mroth@khanacademy.org","sentAt":"2015-04-14T16:04:25Z","receivedAt":"2015-04-14T16:04:25Z","isPatch":false,"sender":{"key":"mroth@khanacademy.org","avatar":null},"body":"Using git 2.3.5 (on darwin, installed via homebrew), when executing a\nscript via the commit-msg githook, the following gets *prepended* to\nthe $PATH for the subprocess:\n\n /usr/local/Cellar/git/2.3.5/libexec/git-core:/usr/local/Cellar/git/2.3.5/libexec/git-core:/usr/local/bin:{rest\nof path...}\n\nI can't find any documentation about this path modification behavior\nin the git docs, and I'm not familiar enough with the source code to\nlocate it there either.\n\nIn our case, the prepending of /usr/local/bin is particularly\nproblematic, as it effectively reorders our chosen PATH hierarchy (in\nwhich user-space versions of commands are picked up prior to system\ninstalled ones).\n\n(It's also curious that the git-core directory gets prepended twice,\nbut that doesn't cause us any particular issues.)\n\nMy questions:\n - what is the expected PATH modification behavior for subprocesses of\ngit-hooks? Is this documented anywhere?\n - what would be causing /usr/local/bin to be prepended here, and can\nit be adjusted via preference?\n\nThanks!\n"},{"id":"259360","messageId":"xmqqk2xe39zt.fsf@gitster.dls.corp.google.com","threadId":"39073","inReplyTo":"CAKuTQSGEmHHr-c+Tc2jM-JPkx6+_f3gp8Zjj8EuQy_e4=PvMzg@mail.gmail.com","subject":"Re: PATH modifications for git-hook processes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-14T17:17:26Z","receivedAt":"2015-04-14T17:17:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthew Rothenberg writes:\n\n> - what is the expected PATH modification behavior for subprocesses of\n> git-hooks? Is this documented anywhere?\n> - what would be causing /usr/local/bin to be prepended here, and can\n> it be adjusted via preference?\n\nThis is not limited to hooks and very much deliberate, I think. In\norder to make sure anything that is called from \"git\" wrapper gets\npicked up from GIT_EXEC_PATH so that the matching version of the git\nsubprogram is used, \"git \" does this before running \"git-\"\n(in git.c):\n\n\t/*\n\t * We use PATH to find git commands, but we prepend some higher\n\t * precedence paths: the \"--exec-path\" option, the GIT_EXEC_PATH\n\t * environment, and the $(gitexecdir) from the Makefile at build\n\t * time.\n\t */\n\tsetup_path();\n\nAnd setup_path() is defined in exec_cmd.c to start the new PATH with\ngit-exec-path, and then the path to the running \"git\" itself, and\nthen finally the external PATH.\n"},{"id":"259411","messageId":"CAKuTQSGapeUeZptdX1=Uv441Moo6X19RNR0oySU--F+Kj6Xz=w@mail.gmail.com","threadId":"39073","inReplyTo":"xmqqk2xe39zt.fsf@gitster.dls.corp.google.com","subject":"Re: PATH modifications for git-hook processes","fromName":"Matthew Rothenberg","fromEmail":"mroth@khanacademy.org","sentAt":"2015-04-15T15:00:20Z","receivedAt":"2015-04-15T15:00:20Z","isPatch":false,"sender":{"key":"mroth@khanacademy.org","avatar":null},"body":"Hmm, this all makes sense as to why it's happening, thank you. In my\ncase the ` /usr/local/Cellar/git/2.3.5/libexec/git-core` (git\n--exec-path) does give all the proper binaries and sub-binaries. It\nshows up twice because the GIT_EXEC_PATH environment variable is used\ntoo (which is the same in my case since it hasn't been overriden).\nThe /usr/local/bin therefore comes from **the path to the running\n\"git\" itself**.\n\nThere still seems to be a potential issue I can't figure out how to\nwork around with this. If **the path to the running \"git\" itself** is\nin /usr/local/bin or some other common area, then that would still\nalways get prepended prior to external PATH -- which means **other**\nexternal programs will inherit precedence overriding the system PATH\npreferences.\n\nFor example, in our case, many scripts run in our specific Python\nenvironment, which ala virtualenv is located in a user-specific path\n(e.g. ~/.virtualenv/foo/bin/python), which appears earlier in the user\nPATH so it affects all shell processes using `#!/usr/bin/env python`.\nWhen a git-exec prepends /usr/local/bin, the system installed Python\nis used instead.\n\nThere are other use cases I can think of that would cause this issue\nas well -- user provides more recent version of \"bazfoo\" program in\n~/bin which they prepend of their system PATH, git-exec then prepends\nshared path of a system binary directory which also contains older\nversion of bazfoo, older version then gets used instead.\n\nSo, I guess what I'm looking for is:\n - A way to prevent the **path to the running \"git\" itself** portion\nof setup_path from firing, (OR)\n - A way to specify (via env var?) paths that must remain in high\nprecedence even during a git-exec, e.g.:\n NEWPATH = [git --exec-path] : [GIT_EXEC_PATH] :\n[$PROPOSED_HIGH_PRECENDENCE_PATH] : ['git itself' path] : [$PATH] (OR)\n - A way to refine git-exec default behavior to avoid this edge case\n(my C is a little rusty but I'm happy to try to help out if we can\nthink of a good logic), (OR)\n - Something else clever I am not aware of.\n\nThanks so much for your assistance.\n\nOn Tue, Apr 14, 2015 at 1:17 PM, Junio C Hamano wrote:\n> Matthew Rothenberg writes:\n>\n>> - what is the expected PATH modification behavior for subprocesses of\n>> git-hooks? Is this documented anywhere?\n>> - what would be causing /usr/local/bin to be prepended here, and can\n>> it be adjusted via preference?\n>\n> This is not limited to hooks and very much deliberate, I think. In\n> order to make sure anything that is called from \"git\" wrapper gets\n> picked up from GIT_EXEC_PATH so that the matching version of the git\n> subprogram is used, \"git \" does this before running \"git-\"\n> (in git.c):\n>\n> /*\n> * We use PATH to find git commands, but we prepend some higher\n> * precedence paths: the \"--exec-path\" option, the GIT_EXEC_PATH\n> * environment, and the $(gitexecdir) from the Makefile at build\n> * time.\n> */\n> setup_path();\n>\n> And setup_path() is defined in exec_cmd.c to start the new PATH with\n> git-exec-path, and then the path to the running \"git\" itself, and\n> then finally the external PATH.\n"},{"id":"259458","messageId":"20150416061732.GA5612@peff.net","threadId":"39073","inReplyTo":"CAKuTQSGapeUeZptdX1=Uv441Moo6X19RNR0oySU--F+Kj6Xz=w@mail.gmail.com","subject":"Re: PATH modifications for git-hook processes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-16T06:17:33Z","receivedAt":"2015-04-16T06:17:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 15, 2015 at 11:00:20AM -0400, Matthew Rothenberg wrote:\n\n> So, I guess what I'm looking for is:\n> - A way to prevent the **path to the running \"git\" itself** portion\n> of setup_path from firing, (OR)\n\nYeah, this behavior leaves me somewhat confused. It is obviously\ndangerous (since we have no clue what else is in the directory along\nwith git, as opposed to the exec-path, which contains only git\nprograms), and that is biting you here. But is it actually doing any\ngood?\n\nSurely we don't need to find the \"git\" executable from that directory;\nit should already be in the exec-path itself. Ditto for any dashed\ncommands (built-ins or external commands) that git ships.\n\nThe only case I could come up with (that works now, but would not work\nif we stopped prepending the argv0 directory to the PATH) is:\n\n mkdir foo\n cp $(which git) foo\n cat >foo/git-bar <<\\EOF\n #!/bin/sh\n echo this external command is not in your PATH!\n EOF\n chmod +x foo/git-bar\n foo/git bar\n\nbut I am not sure that is altogether sane.\n\nI tried to find some reasoning for this behavior in the history, and\nthis is what I found.\n\nWe originally started treating git programs as magical in 77cb17e (Exec\ngit programs without using PATH., 2006-01-10), but it specifically warns\nagainst this:\n\n Modifying PATH is not desirable as it result in behavior differing\n from the user's intentions, as we may end up prepending \"/usr/bin\" to\n PATH.\n\nSo it uses a special git-specific version of exec, and doesn't touch the\nPATH. Later, we did 231af83 (Teach the \"git\" command to handle some\ncommands internally, 2006-02-26), which says at the end:\n\n There's one other change: the search order for external programs is\n modified slightly, so that the first entry remains GIT_EXEC_DIR, but\n the second entry is the same directory as the git wrapper itself was\n executed out of - if we can figure it out from argv[0], of course.\n\nThere was some question of whether this would be a problem[1], but we\nrealized it is OK due to 77cb17e, mentioned above. The use case\ndescribed by Linus is more or less the \"not altogether sane\" scenario I\ndescribed above:\n\n IOW, you can do things like\n\n alias git=/opt/my-git/git\n\n and all the \"git\" commands will automatically work fine, even if you\n didn't know at compile time where you would install them, and you didn't\n set GIT_EXEC_DIR at run-time. It will still first look in GIT_EXEC_DIR,\n but if that fails, it will take the git commands from /opt/my-git/ instead\n of from /usr/bin or whatever.\n\nI think this is pretty much a non-issue for stock git commands (we do\nnot even put them into /opt/my-git these days, so it cannot be helping\nthere). It's really about finding third-party commands you have added.\n\nLater we did 511707d (use only the $PATH for exec'ing git commands,\n2007-10-28) which went back to munging the PATH, and dropping the\nprotection we relied on when doing 231af83 (and causing the breakage\nyou're seeing today).\n\nSo I dunno. I find the current behavior quite questionable. I guess I\ncan see it coming in handy, but as you note it can also cause problems.\nAnd \"put the git-* programs somewhere in your PATH or git's exec-dir if\nyou want to use them\" does not seem like that bad a thing to require\npeople to do.\n\n> - A way to specify (via env var?) paths that must remain in high\n> precedence even during a git-exec, e.g.:\n> NEWPATH = [git --exec-path] : [GIT_EXEC_PATH] :\n> [$PROPOSED_HIGH_PRECENDENCE_PATH] : ['git itself' path] : [$PATH] (OR)\n> - A way to refine git-exec default behavior to avoid this edge case\n> (my C is a little rusty but I'm happy to try to help out if we can\n> think of a good logic), (OR)\n> - Something else clever I am not aware of.\n\nIf we can get away with just dropping this element from the PATH, I'd\nmuch rather do that than try to implement a complicated path-precedence\nscheme.\n\n-Peff\n"},{"id":"259459","messageId":"20150416063137.GA7761@peff.net","threadId":"39073","inReplyTo":"20150416061732.GA5612@peff.net","subject":"Re: PATH modifications for git-hook processes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-16T06:31:37Z","receivedAt":"2015-04-16T06:31:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Apr 16, 2015 at 02:17:32AM -0400, Jeff King wrote:\n\n> So it uses a special git-specific version of exec, and doesn't touch the\n> PATH. Later, we did 231af83 (Teach the \"git\" command to handle some\n> commands internally, 2006-02-26), which says at the end:\n> \n> There's one other change: the search order for external programs is\n> modified slightly, so that the first entry remains GIT_EXEC_DIR, but\n> the second entry is the same directory as the git wrapper itself was\n> executed out of - if we can figure it out from argv[0], of course.\n> \n> There was some question of whether this would be a problem[1], but we\n> realized it is OK due to 77cb17e, mentioned above.\n\nI forgot to include my footnote, which was a link to the thread:\n\n http://thread.gmane.org/gmane.comp.version-control.git/16798\n\n-Peff\n"},{"id":"259783","messageId":"loom.20150422T023408-102@post.gmane.org","threadId":"39073","inReplyTo":"20150416061732.GA5612@peff.net","subject":"Re: PATH modifications for git-hook processes","fromName":"David Rodríguez","fromEmail":"deivid.rodriguez@gmail.com","sentAt":"2015-04-22T00:39:21Z","receivedAt":"2015-04-22T00:39:21Z","isPatch":false,"sender":{"key":"deivid.rodriguez@gmail.com","avatar":"https://gravatar.com/avatar/a1cc6e0d09fa7ad750142933abbcc225b647baa36e04fedda00fad1eb2e7a0e1?d=mp&s=160"},"body":"Jeff King peff.net> writes:\n> \n> If we can get away with just dropping this element from the PATH, I'd\n> much rather do that than try to implement a complicated path-precedence\n> scheme.\n> \n> -Peff\n> \n\nI agree, GIT_EXEC_DIR should be enough and this surprising behavior would be\navoided.\n"},{"id":"259808","messageId":"xmqq1tjcf432.fsf@gitster.dls.corp.google.com","threadId":"39073","inReplyTo":"20150416061732.GA5612@peff.net","subject":"Re: PATH modifications for git-hook processes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-04-22T17:46:57Z","receivedAt":"2015-04-22T17:46:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> IOW, you can do things like\n>\n> alias git=/opt/my-git/git\n>\n> and all the \"git\" commands will automatically work fine, even if you\n> didn't know at compile time where you would install them, and you didn't\n> set GIT_EXEC_DIR at run-time. It will still first look in GIT_EXEC_DIR,\n> but if that fails, it will take the git commands from /opt/my-git/ instead\n> of from /usr/bin or whatever.\n>\n> If we can get away with just dropping this element from the PATH, I'd\n> much rather do that than try to implement a complicated path-precedence\n> scheme.\n\nI am OK with dropping it at a major version boundary with\ndeprecation notice in the release note. Unlike older days, by now,\nGit has become so essential to users' everyday life, and there is\nnot much reason for people to keep the installation of Git they\nbuilt outside their $PATH, and \"alias git=/opt/git/bin/git\" has lost\nmuch of its value, I would think.\n"},{"id":"259813","messageId":"20150422181402.GB3535@peff.net","threadId":"39073","inReplyTo":"xmqq1tjcf432.fsf@gitster.dls.corp.google.com","subject":"[PATCH] stop putting argv[0] dirname at front of PATH","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-22T18:14:02Z","receivedAt":"2015-04-22T18:14:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 22, 2015 at 10:46:57AM -0700, Junio C Hamano wrote:\n\n> > If we can get away with just dropping this element from the PATH, I'd\n> > much rather do that than try to implement a complicated path-precedence\n> > scheme.\n> \n> I am OK with dropping it at a major version boundary with\n> deprecation notice in the release note. Unlike older days, by now,\n> Git has become so essential to users' everyday life, and there is\n> not much reason for people to keep the installation of Git they\n> built outside their $PATH, and \"alias git=/opt/git/bin/git\" has lost\n> much of its value, I would think.\n\nActually, on looking further into it, I am not sure that the use-case\noriginally presented hasn't simply been broken since 2007. The patch\nbelow is trivial, but I've tried to summarize the situation in the\ncommit message.\n\nIf we are really breaking workflows, I agree on the deprecation. But I\nthink we may not be, in which case it would be fine (IMHO) to skip the\ndeprecation notice.\n\n-- >8 --\nSubject: stop putting argv[0] dirname at front of PATH\n\nWhen the \"git\" wrapper is invoked, we prepend the baked-in\nexec-path to our PATH, so that any sub-processes we exec\nwill all find the git-foo commands that match the wrapper\nversion.\n\nIf you invoke git with an absolute path, like:\n\n /usr/bin/git foo\n\nwe also prepend \"/usr/bin\" to the PATH. This was added long\nago by by 231af83 (Teach the \"git\" command to handle some\ncommands internally, 2006-02-26), with the intent that\nthings would just work if you did something like:\n\n cd /opt\n tar xzf premade-git-package.tar.gz\n alias git=/opt/git/bin/git\n\nas we would then find all of the related external commands\nin /opt/git/bin. I.e., it made git runtime-relocatable,\nsince at the time of 231af83, we installed all of the git\ncommands into $(bindir). But these days, that is not enough.\nSince f28ac70 (Move all dashed-form commands to libexecdir,\n2007-11-28), we do not put commands into $(bindir), and you\nactually need to convert \"/usr/bin\" into \"/usr/libexec\". And\nnot just for finding binaries; we want to find $(sharedir),\netc, the same way. The RUNTIME_PREFIX build knob does this\nthe right way, by assuming a sane hierarchy rooted at\n\"$prefix\" when we run \"$prefix/bin/git\", and inferring\n\"$prefix/libexec/git-core\", etc.\n\nSo this feature (prepending the argv[0] dirname to the PATH)\nis broken for providing a runtime prefix, and has been for\nmany years. Does it do anything for other cases?\n\nFor the \"git\" wrapper itself, as well as any commands\nshipped by \"git\", the answer is no. Those are already in\ngit's exec-path, which is consulted first. For third-party\ncommands which you've dropped into the same directory, it\ndoes include them. So if you do\n\n cd /opt\n tar xzf git-built-specifically-for-opt-git.tar.gz\n cp third-party/git-foo /opt/git/bin/git-foo\n alias git=/opt/git/bin/git\n\nit does mean that we will find the third-party \"git-foo\",\neven if you do not put /opt/git/bin into your $PATH. But\nthe flipside of this is that we will bump the precedence of\n_other_ third-party tools that happen to be in the same\ndirectory as git. For example, consider this setup:\n\n 1. Git is installed by the system in /usr/bin. There are\n other system utilities in /usr/bin. E.g., a system\n \"vi\".\n\n 2. The user installs tools they prefer in /usr/local/bin.\n E.g., vim with a \"vi\" symlink. They set their PATH to\n /usr/local/bin:/usr/bin to prefer their custom tools.\n\n 3. Running /usr/bin/git puts \"/usr/bin\" at the front of\n their PATH. When git invokes the editor on behalf of\n the user, they get the system vi, not their normal vim.\n\nThere are other variants of this, including overriding\nsystem ruby and python (which is quite common using tools\nlike \"rvm\" and \"virtualenv\", which use relocatable\nhierarchies and $PATH settings to get a consistent\nenvironment).\n\nGiven that the main motivation for git pulling the argv[0]\ndirname into the PATH has been broken for years, that the\nremaining cases are obscure and unlikely (and easily fixed\nby the user just setting up their $PATH sanely), and that\nthe behavior is hurting real, reasonably common use cases,\nit's not worth continuing to do so.\n\nSigned-off-by: Jeff King \n---\nIf people _are_ interested in relocatable binary packages, I think\nRUNTIME_PREFIX is the right way forward. But note that you can't just\nflip on RUNTIME_PREFIX on non-Windows systems, as some invocations will\nget the full path to the executable, and others see just \"git\". You'd\nneed to convert that into an absolute path (either by searching the\n$PATH, or doing something system-specific like looking in /proc/$$/exe).\n\n exec_cmd.c | 1 -\n 1 file changed, 1 deletion(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 8ab37b5..e85f0fd 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -96,7 +96,6 @@ void setup_path(void)\n \tstruct strbuf new_path = STRBUF_INIT;\n \n \tadd_path(&new_path, git_exec_path());\n-\tadd_path(&new_path, argv0_path);\n \n \tif (old_path)\n \t\tstrbuf_addstr(&new_path, old_path);\n-- \n2.4.0.rc2.498.g02440db\n"},{"id":"259814","messageId":"CAPig+cR1aAk053Lptq-vpsKtVP2nt9RF9YJxhNSicshEk7Ps7g@mail.gmail.com","threadId":"39073","inReplyTo":"20150422181402.GB3535@peff.net","subject":"Re: [PATCH] stop putting argv[0] dirname at front of PATH","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-04-22T18:23:27Z","receivedAt":"2015-04-22T18:23:27Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Apr 22, 2015 at 2:14 PM, Jeff King wrote:\n> Subject: stop putting argv[0] dirname at front of PATH\n>\n> When the \"git\" wrapper is invoked, we prepend the baked-in\n> exec-path to our PATH, so that any sub-processes we exec\n> will all find the git-foo commands that match the wrapper\n> version.\n> [...]\n> Given that the main motivation for git pulling the argv[0]\n\ns/pulling/putting/\n\n> dirname into the PATH has been broken for years, that the\n> remaining cases are obscure and unlikely (and easily fixed\n> by the user just setting up their $PATH sanely), and that\n> the behavior is hurting real, reasonably common use cases,\n> it's not worth continuing to do so.\n>\n> Signed-off-by: Jeff King \n> ---\n> diff --git a/exec_cmd.c b/exec_cmd.c\n> index 8ab37b5..e85f0fd 100644\n> --- a/exec_cmd.c\n> +++ b/exec_cmd.c\n> @@ -96,7 +96,6 @@ void setup_path(void)\n> struct strbuf new_path = STRBUF_INIT;\n>\n> add_path(&new_path, git_exec_path());\n> - add_path(&new_path, argv0_path);\n>\n> if (old_path)\n> strbuf_addstr(&new_path, old_path);\n> --\n> 2.4.0.rc2.498.g02440db\n"},{"id":"259816","messageId":"20150422183612.GD3535@peff.net","threadId":"39073","inReplyTo":"CAPig+cR1aAk053Lptq-vpsKtVP2nt9RF9YJxhNSicshEk7Ps7g@mail.gmail.com","subject":"Re: [PATCH] stop putting argv[0] dirname at front of PATH","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-22T18:36:12Z","receivedAt":"2015-04-22T18:36:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 22, 2015 at 02:23:27PM -0400, Eric Sunshine wrote:\n\n> On Wed, Apr 22, 2015 at 2:14 PM, Jeff King wrote:\n> > Subject: stop putting argv[0] dirname at front of PATH\n> >\n> > When the \"git\" wrapper is invoked, we prepend the baked-in\n> > exec-path to our PATH, so that any sub-processes we exec\n> > will all find the git-foo commands that match the wrapper\n> > version.\n> > [...]\n> > Given that the main motivation for git pulling the argv[0]\n> \n> s/pulling/putting/\n\nHeh. Too much git for me, I think.\n\n-Peff\n"},{"id":"259823","messageId":"20150422192317.GI5467@google.com","threadId":"39073","inReplyTo":"20150422181402.GB3535@peff.net","subject":"Re: [PATCH] stop putting argv[0] dirname at front of PATH","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2015-04-22T19:23:17Z","receivedAt":"2015-04-22T19:23:17Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJeff King wrote:\n\n> This was added long\n> ago by by 231af83 (Teach the \"git\" command to handle some\n> commands internally, 2006-02-26), with the intent that\n> things would just work if you did something like:\n>\n> cd /opt\n> tar xzf premade-git-package.tar.gz\n> alias git=/opt/git/bin/git\n>\n> as we would then find all of the related external commands\n> in /opt/git/bin. I.e., it made git runtime-relocatable,\n> since at the time of 231af83, we installed all of the git\n> commands into $(bindir).\n[...]\n> And\n> not just for finding binaries; we want to find $(sharedir),\n> etc, the same way. The RUNTIME_PREFIX build knob does this\n> the right way\n\nMakes sense. For the reason you say (templatedir, etc) I am surprised\nto hear that that was the motivation, but I can't find any other.\n\n[...]\n> Signed-off-by: Jeff King \n\nFor what it's worth,\nReviewed-by: Jonathan Nieder \n\n[...]\n> But note that you can't just\n> flip on RUNTIME_PREFIX on non-Windows systems, as some invocations will\n> get the full path to the executable, and others see just \"git\". You'd\n> need to convert that into an absolute path (either by searching the\n> $PATH, or doing something system-specific like looking in /proc/$$/exe).\n\nYep --- /proc/self/exe should work okay if someone wants \"portable\ngit\" to work on Linux.\n\nThanks,\nJonathan\n"},{"id":"259838","messageId":"20150422200019.GE27656@peff.net","threadId":"39073","inReplyTo":"20150422192317.GI5467@google.com","subject":"Re: [PATCH] stop putting argv[0] dirname at front of PATH","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-04-22T20:00:19Z","receivedAt":"2015-04-22T20:00:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Apr 22, 2015 at 12:23:17PM -0700, Jonathan Nieder wrote:\n\n> > And\n> > not just for finding binaries; we want to find $(sharedir),\n> > etc, the same way. The RUNTIME_PREFIX build knob does this\n> > the right way\n> \n> Makes sense. For the reason you say (templatedir, etc) I am surprised\n> to hear that that was the motivation, but I can't find any other.\n\nThe Makefile was much less mature, then, so I wondered if maybe those\nthings came later (certainly the munging of $PATH that introduced the\nproblems came later, as at the time we had a special \"we are exec-ing a\ngit command\" custom version of execvp).\n\nBut no, the template directory did indeed exist then. I think it was\nalways a half-baked idea (and got much worse when we stopped putting\ngit-foo into $bindir).\n\nThe relevant thread (which I think I linked the other day) is:\n\n http://article.gmane.org/gmane.comp.version-control.git/16798\n\n-Peff\n"}]}