Re: Plugin mechanism(s) for Git?

[Jeff King <peff@peff.net>]

On Sat, Jul 16, 2016 at 07:31:25AM +0200, Duy Nguyen wrote:

> >> > I wouldn’t be too quick to dismiss dynamically loaded libraries as
> >> > there are some distinct advantages over the other patterns especially
> >> > performance and simplicity.  I realize it requires us to version the
> >> > ABI but there are established patterns to manage this.  It also isn’t
> >> > that much different than us having to freeze or version the protocol
> >> > for communicating with a remote-helper.
> >
> > (re-adding dropped CCs)
> >
> > The critical difference is protocols can be tested and debugged
> > in a language/tool-independent way.
> 
> Not using dynamic libraries also makes it possible for other git
> reimplementations to reuse the same plugins.

Good point.

I think for the ref backends (which so far are the main pluggable thing
that people expect to link in), the assumption was that the on-disk
formats would be documented, and implementations would then write their
own plugins to match the on-disk formats.

I think all of the other implementations _except_ core git already have
their own internal pluggable ref formats (I know libgit2 and JGit do).

In theory if Git defines the API for the plugin to meet, then one could
use those plugins with other implementations. In practice, I think ref
plugins will also make use of Git functions (even things as simple as
xmalloc), and the ABI there is anything but stable. So I think ref
backends are "pluggable" in the sense of "configurable", but not in
the sense of dynamically linking third party code that git has never
seen.

Likewise, I don't think licensing issues have really been discussed. I'd
think at this point that any ref backends would need to be GPL, as they
are quite intimately part of git, and not true pluggable modules.

-Peff