> On 15 Jul 2016, at 08:46, Christian Couder <christian.couder@xxxxxxxxx> wrote: > > [...] > > The current topics/work I can think of are: > > - the ref backend work by Michael based on Ronnie Sahlberg's and others' work, > - the smudge/clean filters work by Joey and Lars, > - the watchman/index helper work by David, Duy and Ben, > - the external ODB work by Peff and myself. > > They all have a need to talk to potentially different > backends/external processes and this need is potentially not well > satisfied by the usual mechanism that Git has traditionally used which > is to have one or a few commands configured and to just launch the > command(s) for each file or object, like what "git difftool" and "git > mergetool" do. > > [...] > > If people think that evolution is better than intelligent design, and > want each current topic/work to just implement what is best for it, > then that's ok for me. If on the other hand standardizing on some ways > to interact with external processes could be helpful to avoid > duplicating mechanisms/code in slightly different and incompatible > ways, then I would be happy to discuss it in a thread that is not > specific to one of the current work. Thanks for this great summary of the problem, Christian! I think a generic plugin mechanism would be great but how would we do it? 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 Unix sockets are not really portable as mentioned by Dscho: http://article.gmane.org/gmane.comp.version-control.git/298432 So far the pipe communication used by the clean/smudge filter seems to be a good option. Maybe we could "standardize" some kind of protocol over pipes? I also like your ODB work and I think it is the right thing to do in the long run. However, I only have a couple of hours a week to work on this and improving an existing solution seemed easier to me (ODB would require bigger changes in Git and Git-LFS for instance). Thanks, Lars-- 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