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

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:

>>> 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