From: Stefan Beller Date: Sat, 28 Feb 2015 00:46:47 GMT Subject: Re: [RFC/PATCH 0/3] protocol v2 Message-ID: In-Reply-To: On Fri, Feb 27, 2015 at 4:33 PM, Junio C Hamano wrote: > On Fri, Feb 27, 2015 at 3:44 PM, Stefan Beller wrote: >> On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano wrote: >>> >>> I am _not_ proposing that we should go this route, at least not yet. >>> I am merely pointing out that an in-place sidegrade from v1 to a >>> protocol that avoids the megabyte-advertisement-at-the-beginning >>> seems to be possible, as a food for thought. >> >> This is a fun thing indeed, though I'd personally feel uneasy with >> such a probe as >> a serious proposal. (Remember somebody 10 years from now wants to enjoy >> reading the source code). > > That cannot be a serious objection, once you realize that NUL + capability > was exactly the same kind of "yes, we have a hole to allow up customize > the protocol". The code to do so may not be pretty, but the code to implement > ended up being reasonably clean with parse_feature_request() and friends. > After all we live in a real world ;-) - new server accepts the connection, but that no-op probe has not arrived yet.". It misdetects the other side as a v1 client and it starts blasting the ref advertisement. A race condition may be a serious objection then? Once people believe the refs can scale fairly well they will use it, which means blasting the ref advertisement will become very worse over time. I'll try to present a 'client asks for options first out of band' instead of the way you describe. Also we should not rely on having holes here and there. (We might run out of holes over time), so I'd rather have the capabilities presented at first which rather opens new holes instead of closing old ones. (assuming we'll never run into megabytes of capabilities over time to have the same trouble again ;)