Dridi Boukelmoune <[email protected]> writes:
> For end users making use of a custom exec path many commands will simply
> fail. Adding git's exec path to the PATH also allows overriding git-sh-*
> scripts, not just adding commands. One can then patch a script without
> tainting their system installation of git for example.
I think the first sentence is where you went wrong. It seems that
you think this ought to work:
rm -fr $HOME/random-stuff
mkdir $HOME/random-stuff
echo "echo happy" >$HOME/random-stuff/git-happy
chmod +x $HOME/random-stuff/git-happy
GIT_EXEC_PATH=$HOME/random-stuff
export GIT_EXEC_PATH
# then...
git happy
But that is not the right/officially sanctioned/kosher way to add
custom git commands (adding your directory that has git-happy in it
to $PATH is). GIT_EXEC_PATH is for the git-cmd binaries and scripts
we ship; it always is used to find non built-in commands, and even
for built-in commands, the command found via alias look-up is invoked
that way.
By insisting on overriding GIT_EXEC_PATH and not populating with
the stuff we ship, you'd need a workaround like your patch just to
make the scripts "work" again. I have a feeling that even with your
patch you wouldn't be able to make non built-in commands, unless you
copy them (or write a thin wrapper that exec's the real thing).
So, instead of the two GIT_EXEC_PATH steps in the above example,
you can do
PATH=$HOME/random-stuff:$PATH
and you'll see "git happy" to work, I would think, without breaking
other things.
