Re: RFC: a plugin architecture for git extensions?

[Jeff King <peff@peff.net>]

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