Re: [PATCH] git-sh: Avoid sourcing scripts with git --exec-path

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

 



Dridi Boukelmoune <dridi.boukelmoune@xxxxxxxxx> 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.



[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]

  Powered by Linux