On Fri, 15 Jul 2016 16:18:28 +0000 (UTC) Ben Peart <peartben@xxxxxxxxx> wrote: > > Thanks for this great summary of the problem, Christian! > > > > I think a generic plugin mechanism would be great but how would we > > do it? > > I’m also very glad to see the discussion about coming up with a good > pattern for how git can interact with external code. I had also > noticed all the in-flight topics as I was searching for a good > pattern to adopt. > > > > > We could dynamically load libraries but this would force us to > > freeze the ABI as mentioned by Duy: > > http://article.gmane.org/gmane.comp.version-control.git/298463 > > > > 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. Using dynamically loaded libraries precludes or greatly complicates creation of plugins written in languages different from C (or C++ FWIW). So that could be okay for some type of plugins (let's call them "core") but not really for third-party / inhouse implementations. -- 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