Re: [PATCH v1 0/3] Git filter protocol

From: Jeff King <peff@peff.net>
Date: Jul 26, 2016, 20:11 UTC
Message-ID: <20160726201105.GB21194@sigill.intra.peff.net>
In-Reply-To: <7DABD0C7-8838-4FEC-B6E5-36F82E521312@gmail.com>

On Sun, Jul 24, 2016 at 01:24:29PM +0200, Lars Schneider wrote:

> What if we would keep the config option "protocol" and make it an "int"? 
> Undefined or version "1" would describe the existing clean/smudge 
> protocol via command line and pipe. Version "2" would be the new protocol?

FWIW, that is what I expected when I saw the word "protocol".

It's possible that we might never need a "v3" protocol specified here, because your v2 protocol should be able to auto-upgrade. That is, if we start a filter and it says "hi, I am speaking protocol 3", then Git knows to speak the requested version from there on (or will barf if it doesn't understand the version).

So you'd only need to say "filter.foo.protocol=v3" if there was some protocol change that broke the initial conversation.

That does mean it is the filter which sets the maximum protocol level, not git. So a filter which can speak v3 or v2 (to work with older versions of git) does not know which to use. That could be solved by specifying

  [filter "foo"]
  smudge = my-filter --version=3

or something.

I'm not sure it's worth thinking too hard about what-ifs here. We should do the simplest thing that will work and avoid painting ourselves into a corner for future upgrades.

Show 9 quoted lines

> > * The way the serialized access to these long-running processes
> >   work in 3/3 would make it harder or impossible to later
> >   parallelize conversion?  I am imagining a far future where we
> >   would run "git checkout ." using (say) two threads, one
> >   responsible for active_cache[0..active_nr/2] and the other
> >   responsible for the remainder.
> I hope this future is not too far away :-) 
> However, I don't think that would be a problem as we could start the
> long-running process once for each checkout thread, no?

That's reasonable if we have a worker-thread model (which seems likely, as that's what we use elsewhere in git), and if the main cost you want to amortize is just process startup (so you pay the cost once per worker, which is a constant factor and not too bad).

It's not a good model if the long-running process wants to amortize other shared costs. For example, persistent https connections. Or even user-interactive authentication steps, where you really would prefer to do them once. The filter can implement its own ad-hoc sharing of resources, but doing that portably is complicated.

Of course having an async protocol between git and the filter is also complicated. Perhaps that's something that could wait for a v3 if somebody really wants it.

-Peff