Re: [PATCH/RFC 4/6] transport: add refspec list parameters to functions

[David Turner <dturner@twopensource.com>]

On Tue, 2016-04-19 at 21:17 -0400, Jeff King wrote:
> On Tue, Apr 19, 2016 at 07:43:11PM -0400, David Turner wrote:
> 
> > On Tue, 2016-04-19 at 19:22 -0400, Jeff King wrote:
> > > You can find previous discussion on the list, but I think the
> > > options
> > > basically are:
> > > 
> > >   1. Something like v2, where the client gets a chance to speak
> > > before
> > >      the advertisement.
> > > 
> > >   2. Some out-of-band way of getting values from the client to
> > > the
> > >      server (so maybe extra command-line arguments for git-over
> > > -ssh,
> > > and
> > >      maybe shoving something after the "\0" for git-daemon, and
> > > of
> > >      course extra parameters for HTTP).
> > > 
> > >   3. The client saying "stop spewing refs at me, I want to give
> > > you a
> > >      ref filter" asynchronously, and accepting a little spew at
> > > the
> > >      beginning of each conversation. That obviously only works
> > > for
> > > the
> > >      full-duplex transports, so you'd probably fall back to (2)
> > > for
> > >      http.
> > 
> > OK, so (2) seems like what I'm doing -- it just happens that I only
> > implemented it for one protocol.
> 
> Right. And I don't mind that approach _if_ we can figure out a way to
> do
> it for all protocols. But I think there are some complications with
> the
> other ones, which means that HTTP will have the ability to grow
> features
> the other protocols do not.

As you note, it appears that git-daemon does sort-of have support for
extra args -- see parse_host_arg.  So it wouldn't be hard to add
something here. Unfortunately, current versions of git die on unknown
args.  So this change would not be backwards-compatible.  We could put
a decider on it so that clients would only try it when explicitly
enabled.  Or we could have clients try it with, and in the event of an
error, retry without.  Neither is ideal, but both are possible.

If I read this code correctly, git-over-ssh will pass through arbitrary
arguments.  So this should be trivial.