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 -- 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