Re: Plugin mechanism(s) for Git?

On Sat, Jul 16, 2016 at 07:31:25AM +0200, Duy Nguyen wrote: > >> > 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

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 11:28 PM, Eric Wong wrote: > Konstantin Khomoutov wrote: >> Ben Peart wrote: >> > > Lars Schneider wrote: >> > > >> > > We could dynamically load libraries but this would force us to >> > > freeze the ABI as

Re: Plugin mechanism(s) for Git?

Konstantin Khomoutov wrote: > Ben Peart wrote: > > > Lars Schneider wrote: > > > > > > We could dynamically load libraries but this would force us to > > > freeze the ABI as mentioned by Duy: > > >

Re: Plugin mechanism(s) for Git?

On Fri, 15 Jul 2016 16:18:28 + (UTC) Ben Peart 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

Re: Plugin mechanism(s) for Git?

Lars Schneider gmail.com> writes: > > 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

Re: Plugin mechanism(s) for Git?

Jeff King peff.net> writes: > > On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote: > > > On Fri, Jul 15, 2016 at 2:18 PM, Jeff King peff.net> wrote: > > > Some features, like the index-helper, aren't quite so easy. One reason > > > is that its data needs to persist as a

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 02:46:28PM +0200, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote: > > Some features, like the index-helper, aren't quite so easy. One reason > > is that its data needs to persist as a cache between multiple git > >

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 2:18 PM, Jeff King wrote: > Some features, like the index-helper, aren't quite so easy. One reason > is that its data needs to persist as a cache between multiple git > invocations. In general, I think it would be nice to solve that by > communicating via

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote: > 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

Re: Plugin mechanism(s) for Git?

Christian Couder writes: > 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

Re: Plugin mechanism(s) for Git?

On Fri, Jul 15, 2016 at 08:46:03AM +0200, Christian Couder wrote: > 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

Re: Plugin mechanism(s) for Git?

> On 15 Jul 2016, at 08:46, Christian Couder 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

Plugin mechanism(s) for Git?

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