From: Jeff King <peff@peff.net>
Date: Tue, 19 Apr 2016 07:14:03 GMT
Subject: Re: [PATCH/RFC 4/6] transport: add refspec list parameters to functions
Message-ID: <20160419071403.GA22577@sigill.intra.peff.net>
In-Reply-To: <xmqqa8kq69i5.fsf@gitster.mtv.corp.google.com>

On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote:

> David Turner <dturner@twopensource.com> writes:
> 
> > Add parameters for a list of refspecs to transport_get_remote_refs and
> > get_refs_list.  These parameters are presently unused -- soon, we will
> > use them to implement fetches which only learn about a subset of refs.
> >
> > Signed-off-by: David Turner <dturner@twopensource.com>
> > ---
> 
> What the code tries to do I am more than halfway happy.  It is
> unfortunate that we cannot do this natively without upgrading the
> protocol in a fundamental way, but this is a nice way to work it
> around only for Git-over-HTTP transport without having to break the
> protocol.

I dunno, I am a bit negative on bringing new features to Git-over-HTTP
(which is already less efficient than the other protocols!) without any
plan for supporting them in the other protocols.

I thought Stefan's v2 protocol work looked quite good, but it seems to
have stalled. The hardest part of that topic is figuring out the upgrade
path. But for git-over-http, we can solve that in the same way that
David is passing in the extra refspecs.

So I'd rather see something like:

  1. Support for v2 "capabilities only" initial negotiation, followed
     by ref advertisement.

  2. Support for refspec-limiting capability.

  3. HTTP-only option from client to trigger v2 on the server.

That's still HTTP-specific, but it has a clear path for converging with
the ssh and git protocols eventually, rather than having to support
magic out-of-band capabilities forever.

It does require an extra round of HTTP request/response, though.

-Peff