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

From: Jeff King <peff@peff.net>
Date: Apr 19, 2016, 07:14 UTC
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:

Show 14 quoted lines

> 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