Re: [RFC/PATCH 0/3] protocol v2

[Stefan Beller <sbeller@google.com>]

On Fri, Feb 27, 2015 at 4:33 PM, Junio C Hamano <gitster@pobox.com> wrote:
> On Fri, Feb 27, 2015 at 3:44 PM, Stefan Beller <sbeller@google.com> wrote:
>> On Fri, Feb 27, 2015 at 3:05 PM, Junio C Hamano <gitster@pobox.com> 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 ;)