On Tue, 2016-04-19 at 03:14 -0400, Jeff King wrote: > On Mon, Apr 18, 2016 at 11:45:54AM -0700, Junio C Hamano wrote: > > > David Turner <dturner@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> > > > --- > > > > 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. Interesting -- can you expand on git-over-http being less efficient? This is the first I'd heard of it. Is it documented somewhere? > 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. This seems way more complicated to me, and not necessarily super -efficient. That is, it seems like rather a lot of work to add a whole round of negotiation and a new protocol, when all we really need is one little tweak. I do think a fetch v2 protocol is potentially interesting for other reasons, but I don't know that I have the time to fully implement it. I wonder if it would be possible to just add these tweaks to v1, and save the v2 work for when someone has the time to implement it? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html