From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 28 Apr 2011 00:10:21 GMT
Subject: Re: RFC: a plugin architecture for git extensions?
Message-ID: <7viptz5j82.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110427234224.GA26854@elie>

Jonathan Nieder <jrnieder@gmail.com> writes:

> Right, my worry was based on the usual way programs find their way
> onto my $PATH.  That is:
>
>  - if they are installed via a package from the distro, they are in
>    /usr/bin.
>
>  - if they are installed with "make install" by the local sysadmin for
>    all users, they are in /usr/local/bin.
>
>  - if I am trying them out for myself, they are in $HOME/opt/foo/bin
>    and when it is time to remove it, "rm -fr $HOME/opt/foo".
>
>  - if I have adopted them, symlinks go in $HOME/bin.
>
> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so
> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still
> works without trouble.  So, barring bugs, each installation method
> does not interfere with the other ones.
>
> Call it overengineering, but I would want a way for installing new git
> commands to have the same attributes (installable by normal users in
> multiuser systems and name conflicts not being a terrible
> administrative burden).

Ok, I wasn't thinking about folks who use repackaged /usr/bin/git together
with their own choice of third-party enhancements.

Probably we would be better off if we define a new set of paths that is
independent from GIT_EXEC_PATH and friends.  The installed git and nothing
else will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at
a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user
has her own customization, and add them to its vocabulary.

Or something like that.  I am not all that interested, but it feels like a
good direction.