Jonathan Nieder <jrnieder@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html