On Mon, May 09, 2011 at 09:28:26PM +1000, Jon Seymour wrote: > > Anyway, with respect to "core.preferredPluginPath", if you do want to go > > in that direction, I don't think any extra git support is needed. You > > can already just do "git config --path core.preferredPluginPath" to get > > the value (with tilde-expansion, even). > > I still think it would be useful for the git wrapper to add > core.preferredPluginPrefix/bin to the PATH, so that there is no > requirement for the user to do this separately via mechanisms that > will differ according to platform, shell etc. Ah, yeah, that probably does make sense. My original conception was that it would be more like "preferredExtensionType" and would be either "user" or "system", from which the installer would select either "$HOME/.gitplugins" or "git --system-extension-dir" respectively. And I was still thinking in those terms, even though the example you showed was obviously an arbitrary path. If you want to go the arbitrary path route, then yeah, it would need to be added to git's expansion list. There is one drawback with that, though. Consider something like this: $ git config core.preferredPluginPrefix /opt/git-plugins $ cd git-foo && ./install [installs in /opt/git-plugins/git-foo] $ git foo ;# works fine [time passes; now you decide you want to install new plugins in your home directory] $ git config core.preferredPluginPrefix $HOME/.gitplugins $ cd git-bar && ./install [installs in $HOME/.gitplugins] $ git bar ;# works fine $ git foo ;# now broken! So there is some value to separating the concept of "these are the paths git looks in" and "this is the path we install into" and enforcing that the latter points to one of the former. -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