Re: Plugin mechanism(s) for Git?

On 15 Jul 2016, at 08:46, Christian Couder [off-list ref] 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