Plugin mechanism(s) for Git?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]