On Sat, May 7, 2011 at 3:23 AM, Jeff King <peff@xxxxxxxx> wrote: > On Sat, May 07, 2011 at 12:07:14AM +1000, Jon Seymour wrote: > >> I think the problem we are trying to solve is this: how to make it as >> easy as possible to install, and get operational, an extension to git. >> >> If git supported the concept of a standard place to put extensions, >> then it could be as simple as: >> >> Â Â unzip -d $(git --plugins-dir) plugin.zip >> >> with no need to configure or choose a prefix and no need to edit the >> an .profile or .bashrc to permanently add a directory to the PATH. > > This seems slightly backwards to me. You are asking git "where should > plugins go?" and then putting them there. But that leaves no room for > plugins going in _multiple_ places. IOW, the usual hierarchy of: > > Â1. distribution-packaged extensions (in /usr/share/git/plugins) > > Â2. local system-wide extensions (in /usr/local/share/git/plugins) > > Â3. per-user extensions (in $HOME/.gitplugins) > Actually, that was part of my RFC - how to let git find places where plugins may be installed. Your suggestions seem good to me. > It seems like we should not be asking git, but _telling_ git about where > our plugins are. I understand that you don't want the user to have to do > any additional steps, and I think that is a reasonable goal. But can't > that be easily accomplished by: > > Â1. The git wrapper learns to look in a set of plugin paths, something > Â Â like: > > Â Â Â foreach path in (list of plugin paths) > Â Â Â Â foreach plugin in "path/*" > Â Â Â Â Â add plugin/bin to PATH > Â Â Â Â Â add plugin/man to MANPATH > > Â2. At compile time, we give some stock system directories like > Â Â /usr/share/git/plugins and /usr/local/share/git/plugins. > Â Â Distribution packages of git override as appropriate for the target > Â Â system. > > Â3. We always check $HOME/.gitplugins by default. > All seems reasonable, assuming that there is a consensus that we need to do something other than recommend installation into /usr/local (or the platform equivalent) and I am not sure that is a given at this point. > Â4. Users can set GIT_PLUGIN_PATH in the environment if they want to do > Â Â something fancy (they can also always just set PATH and MANPATH > Â Â manually if they want, too). > If the need for multiple plugin directories were accepted, then I wonder if there might not be some advantages for the configuration of this path being in git configuration rather than an environment variable? Again, assuming only git, this would provide installation helpers with a standard way to make git aware of such directories that does not depend on the particulars of the platform on which git is installed. > This is how many systems already work. For example, look at how vim > handles plugins. > > Distro-packaged extensions obviously know where to go (the packager > knows their distro's rules). People with personal extensions don't have > to know anything special; their packages go in $HOME/.gitplugins. > > In general I would expect /usr/local/share/git/plugins to be pretty > standard, and not needing of being repeated for admins who want to > install something system-wide. But if you want to be really thorough, > then your "git --plugins-dir" should probably report the "system-wide > but not distro" directory for that (but I would call it something like > "git --system-plugins-dir" or something to make it more clear). > I think that your suggestion of --system-plugins-dir is a good one for the reasons you suggest. > -Peff > -- 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