Re: [RFC] protocol version 2

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 26, 2017, 00:59 UTC
Message-ID: <xmqqbmkuhgfm.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171024183557.GB79163@google.com>

Brandon Williams <bmwill@google.com> writes:

Show 17 quoted lines

> On 10/24, Junio C Hamano wrote:
>> Brandon Williams <bmwill@google.com> writes:
>> 
>> >   <refspec>: When specified, only references matching the given patterns
>> >              are displayed.
>> 
>> I do not think you meant <refspec> here.
>> 
>> The side that is listing what it has has no reason to know what the
>> recipient plans to do with the result, so you must be only sending
>> the LHS of a refspec.  If your explanation says "given patterns",
>> then replace <refspec> with <pattern>.  Do not abuse a term that has
>> specific and established meaning for something else.
>
> Yes, you're right i intended that to mean <pattern> instead so that the
> client could send "refs/heads/*" or some other such pattern and have the
> server limit its output.

Speaking of limiting the bandwidth consumed by the ref advertisement, I think another trick that came up in past discussions may be worth considering, which is to allow the requestor to say, "oh by the way, I made exactly the same request as this one earlier to you, and your response hashed down to this value". The responder may choose to give an incremental response relative to the known result the requestor claims to have.

So for example, a requestor may have made an earlier ls-refs request and can still recall that it got:

	refs/heads/maint	ObjectID A
	refs/heads/master	ObjectID B
	refs/tags/v1.0		ObjectId C

Also assume that these three lines together (textually) hashes to Z.

When the requestor asks about the two hierarchies, it may say "I know you gave a result that hashes to Z" with an additional parameter:

	command=ls-ref
		refspec=refs/heads/*
		refspec=refs/tags/*
		known=Z

If the current response for refs/heads/* and refs/tags/* when fully spelt out were like this (i.e. we updated a ref, gained another, and lost one):

	refs/heads/master	ObjectID D
	refs/tags/v1.0		ObjectId C
	refs/tags/v1.1		ObjectID E

then the responder can send the fully spelt version, or it can choose to say, "It's good that you know the state Z; relative to that, refs/heads/maint no loner exists, refs/heads/master is now at D and refs/tags/v1.1 at E has been added", if the latter results in a shorter response (and if it recognises Z and map it back to the set of refs and their values it responded with).

The "known" request parameter could further be refined (I do not think this possibility was discussed in the past) to say "among the values I received earlier from you, the ones that match this pattern hashes to this", e.g. the earlier example request might become

	command=ls-ref
		refspec=refs/heads/*
		refspec=refs/tags/*
		known=X for refs/heads/*
		known=Y for refs/tags/*