{"thread":{"id":"46854","subject":"[PATCH] git-sh: Avoid sourcing scripts with git --exec-path","startedAt":"2017-09-28T22:31:46Z","lastAt":"2017-09-29T11:59:14Z","messageCount":6,"participants":["Dridi Boukelmoune","Jonathan Nieder","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"329132","messageId":"20170928223134.GA30744@varnish","threadId":"46854","inReplyTo":null,"subject":"[PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Dridi Boukelmoune","fromEmail":"dridi.boukelmoune@gmail.com","sentAt":"2017-09-28T22:31:34Z","receivedAt":"2017-09-28T22:31:46Z","isPatch":true,"sender":{"key":"dridi.boukelmoune@gmail.com","avatar":null},"body":"For end users making use of a custom exec path many commands will simply\nfail. Adding git's exec path to the PATH also allows overriding git-sh-*\nscripts, not just adding commands. One can then patch a script without\ntainting their system installation of git for example.\n\nSigned-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>\n---\n\nHi,\n\nI've been bothered by this problem ever since I upgraded my system to\nFedora 26, and I grew tired of locally patching git-sh-setup after every\ngit-core update. So I decided to look at the instructions on how to send\npatches to the Git project, and here is my first patch.\n\nI hope you will find it appropriate, I didn't study the test suite to\nhave it enforce that files shouldn't be sourced from the \"system\"\ninstallation. I couldn't reproduce it after a quick look, and I'm not\nfamiliar enough to tinker with it yet, so I reached my trial&error quota\nbefore I could figure things out.\n\nBest Regards,\nDridi\n\n Documentation/CodingGuidelines            | 22 ++++++++++++++++++++++\n contrib/convert-grafts-to-replace-refs.sh |  3 ++-\n contrib/rerere-train.sh                   |  3 ++-\n contrib/subtree/git-subtree.sh            |  1 -\n git-sh-setup.sh                           |  2 +-\n 5 files changed, 27 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines\nindex c4cb5ff0d..fdc0d3318 100644\n--- a/Documentation/CodingGuidelines\n+++ b/Documentation/CodingGuidelines\n@@ -151,6 +151,28 @@ For shell scripts specifically (not exhaustive):\n    interface translatable. See \"Marking strings for translation\" in\n    po/README.\n \n+ - When sourcing a \"git-sh-*\" file using \"git --exec-path\" make sure\n+   to only use its base name.\n+\n+\t(incorrect)\n+\t. \"$(git --exec-path)/git-sh-setup\"\n+\n+\t(correct)\n+\t. git-sh-setup\n+\n+   Otherwise for a user with a custom \"GIT_EXEC_PATH=/foo\" the shell\n+   expects \"/foo:/usr/libexec/git-core/git-sh-setup\" or something\n+   similar depending on the installation. The git command already\n+   adds the git exec path to the regular path before executing a\n+   command.\n+\n+   For scripts that aren't run via the git command, add the git exec\n+   path to the path instead.\n+\n+\t(correct)\n+\tPATH=\"$(git --exec-path):$PATH\"\n+\t. git-sh-setup\n+\n  - We do not write our \"test\" command with \"-a\" and \"-o\" and use \"&&\"\n    or \"||\" to concatenate multiple \"test\" commands instead, because\n    the use of \"-a/-o\" is often error-prone.  E.g.\ndiff --git a/contrib/convert-grafts-to-replace-refs.sh b/contrib/convert-grafts-to-replace-refs.sh\nindex 0cbc917b8..f7d2fab03 100755\n--- a/contrib/convert-grafts-to-replace-refs.sh\n+++ b/contrib/convert-grafts-to-replace-refs.sh\n@@ -5,7 +5,8 @@\n \n GRAFTS_FILE=\"${GIT_DIR:-.git}/info/grafts\"\n \n-. $(git --exec-path)/git-sh-setup\n+PATH=\"$(git --exec-path):$PATH\"\n+. git-sh-setup\n \n test -f \"$GRAFTS_FILE\" || die \"Could not find graft file: '$GRAFTS_FILE'\"\n \ndiff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh\nindex 52ad9e41f..07bad67e6 100755\n--- a/contrib/rerere-train.sh\n+++ b/contrib/rerere-train.sh\n@@ -7,7 +7,8 @@ USAGE=\"$me rev-list-args\"\n \n SUBDIRECTORY_OK=Yes\n OPTIONS_SPEC=\n-. \"$(git --exec-path)/git-sh-setup\"\n+PATH=\"$(git --exec-path):$PATH\"\n+. git-sh-setup\n require_work_tree\n cd_to_toplevel\n \ndiff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh\nindex dec085a23..1d61f75d0 100755\n--- a/contrib/subtree/git-subtree.sh\n+++ b/contrib/subtree/git-subtree.sh\n@@ -32,7 +32,6 @@ squash        merge subtree changes as a single commit\n \"\n eval \"$(echo \"$OPTS_SPEC\" | git rev-parse --parseopt -- \"$@\" || echo exit $?)\"\n \n-PATH=$PATH:$(git --exec-path)\n . git-sh-setup\n \n require_work_tree\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 378928518..12e1220f8 100644\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -44,7 +44,7 @@ git_broken_path_fix () {\n # @@BROKEN_PATH_FIX@@\n \n # Source git-sh-i18n for gettext support.\n-. \"$(git --exec-path)/git-sh-i18n\"\n+. git-sh-i18n\n \n die () {\n \tdie_with_status 1 \"$@\"\n-- \n2.13.5\n\n"},{"id":"329144","messageId":"20170929034856.GB28303@aiede.mtv.corp.google.com","threadId":"46854","inReplyTo":"20170928223134.GA30744@varnish","subject":"Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-29T03:48:56Z","receivedAt":"2017-09-29T03:49:03Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nDridi Boukelmoune wrote:\n\n> For end users making use of a custom exec path many commands will simply\n> fail. Adding git's exec path to the PATH also allows overriding git-sh-*\n> scripts, not just adding commands. One can then patch a script without\n> tainting their system installation of git for example.\n>\n> Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>\n\nThis has been broken for a while, but better late than never to\naddress it.\n\n[...]\n> --- a/Documentation/CodingGuidelines\n> +++ b/Documentation/CodingGuidelines\n> @@ -151,6 +151,28 @@ For shell scripts specifically (not exhaustive):\n>     interface translatable. See \"Marking strings for translation\" in\n>     po/README.\n>  \n> + - When sourcing a \"git-sh-*\" file using \"git --exec-path\" make sure\n> +   to only use its base name.\n> +\n> +\t(incorrect)\n> +\t. \"$(git --exec-path)/git-sh-setup\"\n> +\n> +\t(correct)\n> +\t. git-sh-setup\n\nI wonder if we can make this so intuitive that it doesn't need\nmentioning in CodingGuidelines.  What if the test harness\nt/test-lib.sh were to set a GIT_EXEC_PATH with multiple directories in\nit?  That way, authors of new commands would not have to be careful to\nlook out for this issue proactively because the testsuite would catch\nit.\n\n[...]\n> +++ b/contrib/convert-grafts-to-replace-refs.sh\n> @@ -5,7 +5,8 @@\n>  \n>  GRAFTS_FILE=\"${GIT_DIR:-.git}/info/grafts\"\n>  \n> -. $(git --exec-path)/git-sh-setup\n> +PATH=\"$(git --exec-path):$PATH\"\n> +. git-sh-setup\n\nI wish there were a simple way to do this that doesn't involve\npolluting $PATH with the dashed commands.  E.g. we can do something\nlike\n\n\tOIFS=$IFS\n\tIFS=:\n\tset -f\n\tfor d in $(git --exec-path)\n\tdo\n\t\tif test -e \"$d/git-sh-setup\"\n\t\tthen\n\t\t\t. \"$d/git-sh-setup\"\n\t\t\tbreak\n\t\tfi\n\tdone\n\tset +f\n\tIFS=$OIFS\n\nbut that is not very simple.  Something like\n\n\told_PATH=$PATH\n\tPATH=$(git --exec-path):$PATH\n\t. git-sh-setup\n\tPATH=$old_PATH\n\nlooks like it could work, but it would undo the work git-sh-setup\ndoes to set a sane $PATH on platforms like Solaris.\n\n> --- a/contrib/rerere-train.sh\n> +++ b/contrib/rerere-train.sh\n> @@ -7,7 +7,8 @@ USAGE=\"$me rev-list-args\"\n>  \n>  SUBDIRECTORY_OK=Yes\n>  OPTIONS_SPEC=\n> -. \"$(git --exec-path)/git-sh-setup\"\n> +PATH=\"$(git --exec-path):$PATH\"\n> +. git-sh-setup\n\nThis makes me similarly unhappy about PATH pollution, but it may be\nthat there's nothing to be done about that.\n\n[...]\n> --- a/contrib/subtree/git-subtree.sh\n> +++ b/contrib/subtree/git-subtree.sh\n> @@ -32,7 +32,6 @@ squash        merge subtree changes as a single commit\n>  \"\n>  eval \"$(echo \"$OPTS_SPEC\" | git rev-parse --parseopt -- \"$@\" || echo exit $?)\"\n>  \n> -PATH=$PATH:$(git --exec-path)\n>  . git-sh-setup\n\nThis looks like a change that could be separated into a separate\npatch, both because it is to contrib/subtree (which is maintained\nseparately) and because it is not necessary for the goal described in\nthis patch's commit message.  I do like this change, since it improves\nconsistency with other commands.\n\n> --- a/git-sh-setup.sh\n> +++ b/git-sh-setup.sh\n> @@ -44,7 +44,7 @@ git_broken_path_fix () {\n>  # @@BROKEN_PATH_FIX@@\n>  \n>  # Source git-sh-i18n for gettext support.\n> -. \"$(git --exec-path)/git-sh-i18n\"\n> +. git-sh-i18n\n\nDo git-mergetool--lib.txt, git-parse-remote.txt, git-sh-i18n.txt,\nand git-sh-setup.txt in Documentation/ need the same treatment?\n\nSummary: I like the goal of this patch but I am nervous about the\nside-effect it introduces of PATH pollution.  Is there a way around\nthat?  If there isn't, then this needs a few tweaks and then it should\nbe ready to go.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"329146","messageId":"xmqqtvzmxij5.fsf@gitster.mtv.corp.google.com","threadId":"46854","inReplyTo":"20170929034856.GB28303@aiede.mtv.corp.google.com","subject":"Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-29T03:58:38Z","receivedAt":"2017-09-29T03:58:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> This has been broken for a while, but better late than never to\n> address it.\n\nI am not sure if this is broken in the first place.  We do want to\nmake sure that the scripted porcelains will source the shell helper\nlibrary from matching Git release.  The proposed patch goes directly\nagainst that and I do not see how it could be an improvement.\n\n>> --- a/contrib/rerere-train.sh\n>> +++ b/contrib/rerere-train.sh\n>> @@ -7,7 +7,8 @@ USAGE=\"$me rev-list-args\"\n>>  \n>>  SUBDIRECTORY_OK=Yes\n>>  OPTIONS_SPEC=\n>> -. \"$(git --exec-path)/git-sh-setup\"\n>> +PATH=\"$(git --exec-path):$PATH\"\n>> +. git-sh-setup\n>\n> This makes me similarly unhappy about PATH pollution, but it may be\n> that there's nothing to be done about that.\n\nTo me, all the instances of the unhappiness in your review seem to\nbe caused by the unjustified declaration that it is bad to source\nfrom the directory \"gti --exec-path\" reports.  If a user wants to\ntweak things Git does, why should the user futz with his own copy\nof sh-setup and force scripted Porcelains to read from it, which\nwould only affect the scripted Porcelains and have no chance of\naffecting compiled commands?  Is building from the source so bad for\nan open source tool?\n"},{"id":"329148","messageId":"20170929042129.GA34269@aiede.mtv.corp.google.com","threadId":"46854","inReplyTo":"xmqqtvzmxij5.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2017-09-29T04:21:29Z","receivedAt":"2017-09-29T04:21:55Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> This has been broken for a while, but better late than never to\n>> address it.\n>\n> I am not sure if this is broken in the first place.  We do want to\n> make sure that the scripted porcelains will source the shell helper\n> library from matching Git release.  The proposed patch goes directly\n> against that and I do not see how it could be an improvement.\n\nIt used to be that git allowed setting a colon-separated list of paths\nin GIT_EXEC_PATH.  (Very long ago, I relied on that feature.)  If we\ncan restore that functionality without too much cost, then I think\nit's worthwhile.\n\nBut the cost in this patch for that is pretty high.  And\n\n\t$ git log -S'$(git --exec-path)/'\n\ntells me that colon-separated paths in GIT_EXEC_PATH did not work for\nsome use cases as far back as 2006.  Since 2008 the documentation has\nencouraged using \"git --exec-path\" in a way that does not work with\ncolon-separated paths, too.  I hadn't realized it was so long.  Given\nthat it hasn't been supported for more than ten years, I was wrong to\nread this as a bug report --- instead, it's a feature request.\n\nIn that context, this cost is likely not worth paying.\n\nI wonder if there's another way to achieve this patch's goal.  E.g.\nwhat if there were a way to specify some paths git could search for\ncustom commands, separate from \"git --exec-path\"?\n\nPutting the custom commands on the $PATH seems nicer unless you're\ntrying to override the implementation of an existing git command.\nAnd we already discourage overriding the implementation of an existing\ngit command (as it's open source, you can patch them instead), so...\n\nAnother possible motivation (the one that led me to use this mechnism\nlong ago) is avoiding providing the dashed form git-$cmd in $PATH.  I\nthink time has shown that having git-$cmd in $PATH is not too painful.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"329151","messageId":"xmqqh8vmxfoq.fsf@gitster.mtv.corp.google.com","threadId":"46854","inReplyTo":"20170928223134.GA30744@varnish","subject":"Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-09-29T05:00:05Z","receivedAt":"2017-09-29T05:00:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dridi Boukelmoune <dridi.boukelmoune@gmail.com> writes:\n\n> For end users making use of a custom exec path many commands will simply\n> fail. Adding git's exec path to the PATH also allows overriding git-sh-*\n> scripts, not just adding commands. One can then patch a script without\n> tainting their system installation of git for example.\n\nI think the first sentence is where you went wrong.  It seems that\nyou think this ought to work:\n\n    rm -fr $HOME/random-stuff\n    mkdir $HOME/random-stuff\n    echo \"echo happy\" >$HOME/random-stuff/git-happy\n    chmod +x $HOME/random-stuff/git-happy\n    GIT_EXEC_PATH=$HOME/random-stuff\n    export GIT_EXEC_PATH\n    # then...\n    git happy\n\nBut that is not the right/officially sanctioned/kosher way to add\ncustom git commands (adding your directory that has git-happy in it\nto $PATH is).  GIT_EXEC_PATH is for the git-cmd binaries and scripts\nwe ship; it always is used to find non built-in commands, and even\nfor built-in commands, the command found via alias look-up is invoked\nthat way.\n\nBy insisting on overriding GIT_EXEC_PATH and not populating with\nthe stuff we ship, you'd need a workaround like your patch just to\nmake the scripts \"work\" again.  I have a feeling that even with your\npatch you wouldn't be able to make non built-in commands, unless you\ncopy them (or write a thin wrapper that exec's the real thing).\n\nSo, instead of the two GIT_EXEC_PATH steps in the above example,\nyou can do\n\n\tPATH=$HOME/random-stuff:$PATH\n\nand you'll see \"git happy\" to work, I would think, without breaking\nother things.\n"},{"id":"329173","messageId":"CAJYncsiou3WjNhvn4YuzjuyqGknSgWmXewFhgD5M1j+Wsmmefw@mail.gmail.com","threadId":"46854","inReplyTo":"xmqqh8vmxfoq.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path","fromName":"Dridi Boukelmoune","fromEmail":"dridi.boukelmoune@gmail.com","sentAt":"2017-09-29T11:58:28Z","receivedAt":"2017-09-29T11:59:14Z","isPatch":true,"sender":{"key":"dridi.boukelmoune@gmail.com","avatar":null},"body":"Hi all,\n\nThanks for the fast feedback, I'll answer everyone in a single email\nif you don't mind.\n\nOn Fri, Sep 29, 2017 at 5:48 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\nsnip\n> I wonder if we can make this so intuitive that it doesn't need\n> mentioning in CodingGuidelines.  What if the test harness\n> t/test-lib.sh were to set a GIT_EXEC_PATH with multiple directories in\n> it?  That way, authors of new commands would not have to be careful to\n> look out for this issue proactively because the testsuite would catch\n> it.\n\nNow that you pointed out that I missed the relevant documentations, I\ndon't think this belongs in the guidelines at all.\n\nsnip\n> Do git-mergetool--lib.txt, git-parse-remote.txt, git-sh-i18n.txt,\n> and git-sh-setup.txt in Documentation/ need the same treatment?\n\nThat is embarrassing, I thought I had done my research properly...\n\n> Summary: I like the goal of this patch but I am nervous about the\n> side-effect it introduces of PATH pollution.  Is there a way around\n> that?  If there isn't, then this needs a few tweaks and then it should\n> be ready to go.\n\nThe PATH is already \"polluted\" when git-* commands are run via git,\nand in the context of a script using git-sh-setup I wouldn't consider\nthat completely irrelevant.\n\nOn Fri, Sep 29, 2017 at 5:58 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> This has been broken for a while, but better late than never to\n>> address it.\n>\n> I am not sure if this is broken in the first place.  We do want to\n> make sure that the scripted porcelains will source the shell helper\n> library from matching Git release.  The proposed patch goes directly\n> against that and I do not see how it could be an improvement.\n\nBut the problem is that just by having a GIT_EXEC_PATH you will source\nan incorrect file name. If there was something like --exec-dir that\nwouldn't take the PATH into account. Before I tried to contribute a\nfix, my local patching of git-sh-setup after git-core upgrades was\nactually this:\n\n    -. \"$(git --exec-path)/git-sh-i18n\"\n    +. \"$(GIT_EXEC_PATH= git --exec-path)/git-sh-i18n\"\n\nThat's not pretty, but it gives the guarantee to source from matching\nGit release. Considering the PATH semantics, this is how I would fix\nit after reading your feedback.\n\nOn Fri, Sep 29, 2017 at 6:21 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Junio C Hamano wrote:\n>> Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>>> This has been broken for a while, but better late than never to\n>>> address it.\n>>\n>> I am not sure if this is broken in the first place.  We do want to\n>> make sure that the scripted porcelains will source the shell helper\n>> library from matching Git release.  The proposed patch goes directly\n>> against that and I do not see how it could be an improvement.\n>\n> It used to be that git allowed setting a colon-separated list of paths\n> in GIT_EXEC_PATH.  (Very long ago, I relied on that feature.)  If we\n> can restore that functionality without too much cost, then I think\n> it's worthwhile.\n>\n> But the cost in this patch for that is pretty high.  And\n>\n>         $ git log -S'$(git --exec-path)/'\n>\n> tells me that colon-separated paths in GIT_EXEC_PATH did not work for\n> some use cases as far back as 2006.  Since 2008 the documentation has\n> encouraged using \"git --exec-path\" in a way that does not work with\n> colon-separated paths, too.  I hadn't realized it was so long.  Given\n> that it hasn't been supported for more than ten years, I was wrong to\n> read this as a bug report --- instead, it's a feature request.\n\nWell, from my perspective it's a bug report, upgrading git caused a\nregression in my setup. I didn't know I was doing it wrong ;)\n\nsnip\n> Another possible motivation (the one that led me to use this mechnism\n> long ago) is avoiding providing the dashed form git-$cmd in $PATH.  I\n> think time has shown that having git-$cmd in $PATH is not too painful.\n\nIn my case, yes, I'm maintaining commands but don't really want to\npollute my general-purpose PATH. But I can live with that and use PATH\ninstead.\n\nOn Fri, Sep 29, 2017 at 7:00 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Dridi Boukelmoune <dridi.boukelmoune@gmail.com> writes:\n>\n>> For end users making use of a custom exec path many commands will simply\n>> fail. Adding git's exec path to the PATH also allows overriding git-sh-*\n>> scripts, not just adding commands. One can then patch a script without\n>> tainting their system installation of git for example.\n>\n> I think the first sentence is where you went wrong.  It seems that\n> you think this ought to work:\n>\n>     rm -fr $HOME/random-stuff\n>     mkdir $HOME/random-stuff\n>     echo \"echo happy\" >$HOME/random-stuff/git-happy\n>     chmod +x $HOME/random-stuff/git-happy\n>     GIT_EXEC_PATH=$HOME/random-stuff\n>     export GIT_EXEC_PATH\n>     # then...\n>     git happy\n\nExactly!\n\n> But that is not the right/officially sanctioned/kosher way to add\n> custom git commands (adding your directory that has git-happy in it\n> to $PATH is).  GIT_EXEC_PATH is for the git-cmd binaries and scripts\n> we ship; it always is used to find non built-in commands, and even\n> for built-in commands, the command found via alias look-up is invoked\n> that way.\n\nThe git(1) manual says:\n\n> This can also be controlled by setting the GIT_EXEC_PATH environment\n> variable.\n\nThis is why I set up my system like this years ago. The manual could\nsay when the envvar usage is appropriate.\n\n> By insisting on overriding GIT_EXEC_PATH and not populating with\n> the stuff we ship, you'd need a workaround like your patch just to\n> make the scripts \"work\" again.  I have a feeling that even with your\n\nI forgot about that, and I actually had to look at my bashrc to realize that\nGIT_EXEC_PATH completely overrides the exec path. I did this, and\nforgot about it once I was done:\n\n    export GIT_EXEC_PATH=<my-path>:\"$(GIT_EXEC_PATH= git --exec-path)\"\n\nSo for so while I managed to convince myself that git --exec-path\nalways includes the local installation path. Today I re-learn.\n\n> patch you wouldn't be able to make non built-in commands, unless you\n> copy them (or write a thin wrapper that exec's the real thing).\n>\n> So, instead of the two GIT_EXEC_PATH steps in the above example,\n> you can do\n>\n>         PATH=$HOME/random-stuff:$PATH\n>\n> and you'll see \"git happy\" to work, I would think, without breaking\n> other things.\n\nThat creates a gap between git-core commands being in libexec outside\nof the PATH and my git-* commands having to be in the PATH even though\nthey aren't meant to be executed directly.\n\nShould I attempt a new patch? I'd make sure to source by neutering\nGIT_EXEC_PATH and update the relevant documentation this time.\n\nThanks for the review, it has been very instructive, even for a simple shell\nproblem!\n\nDridi\n"}]}