Hi, It seems to me that there are many current topics/patch series in flight that are about making Git interact with external code/processes and that it could be interesting to step back a bit and see if we could find a common approach/mechanism for at least some of these current topics.
(This is also inspired by private discussions with AEvar, thanks to him, and by the fact that I am now also working for GitLab on the long run on external ODB for large file support.) 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. One reason that the traditional mechanism might not work well is of course performance. This traditional mechanism still is very interesting because it is very easy to setup and experiment with. One way to extend it for better performance is to require that the configured command should be able to deal with a number or a stream of files or objects (instead of just one objec/file) that are passed to it. It looks like that is what Lars wants for smudge/clean filters. Another way is to have the external command run as a daemon, like what Duy and David implemented for the index-helper. And a more integrated way is to require the external code to implement an API and to be compiled along with Git which looks like the approach taken by the ref backend work. 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, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
