On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote:
> David Turner <dtur...@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 <dtur...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
