Junio C Hamano wrote: > I was thinking it, and the location git-work binary gets installed, should > depend on where "git" and its subcommand binaries are installed. The word > plug-in mentioned in the thread implied that whatever plugs in is not by > itself full fledged thing that is useful standalone, so it seemed a very > natural thing to do. With the goal of making some commands available to git without putting them on the $PATH in mind, this all makes more sense. Sorry I missed that before. >> Or is the idea to blindly install (a symlink to) git-work to $(git >> --exec-path)/ rather than a place on the $PATH? > > You can call it _blindly_ if you like, but that is what I meant. "git" > tells where the binary and help material for a "plugin" to be installed, > so that it can find them where it expects to. 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). A simple way would be to introduce GIT_MAN_PATH as you described and to teach "git help" to accept a GIT_EXEC_PATH consisting of a colon-delimited (semicolon-delimited on Windows) list of directories. -- 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