Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 8, 2016, 17:58 UTC
Message-ID: <20160708175821.GA29326@google.com>
In-Reply-To: <xmqqh9c1nlvm.fsf@gitster.mtv.corp.google.com>

Hi,

Junio C Hamano wrote:

> Stefan Beller <sbeller@google.com> writes:

Show 5 quoted lines

>>> More importantly, if we plan to make this configurable and not make
>>> the limit a hardwired constant of the wire protocol, it may be
>>> better to advertise push-options capability with the limit, e.g.
>>> "push-options=32" (or even "push-options=1024/32"), so that the
>>> client side can count and abort early?

Sorry to butt into the conversation late, but: I am not yet convinced.

Is the idea that if the push options were very large, this would save the client from the cost of sending them? But this comes with a downside: the server doesn't get to send an error message about where the maximum number of push options can come from (e.g., with a link to a page where the limit can be adjusted, or with an explanation of when clients tend to run into this problem and what they should do instead).

So I'd like to propose an alternative. What if the client tells the server the number of push options early on (and possibly also a cap on the length of those push options)? That way, the client doesn't have to waste bit sending the push options but the server gets an opportunity to send a helpful error message on sideband 3.

	server> HEAD\0push-options ...
	client> ... commands ...
	client> push-options 2
	client> my-first-option
	client> my-second-option

Thanks, Jonathan