Re: Request for detailed documentation of git pack protocol

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 3, 2009, 22:16 UTC
Message-ID: <7vzlcp55g3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <200906040004.18594.jnareb@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

> 1. Server sends space separated list of capabilities it support. It
>    MUST NOT send capabilities it *does not* support. It MAY NOT send
>    "include-tag" if there are no tag objects (or is it SHOULD NOT?).

I doubt RFC 2119 lingo would include MAY NOT, as it is ambiguous especially to non-native speakers (like me). You meant to say "MAY omit sending", perhaps, but in general capabilies are what you _can_ do at the protocol level, and in my opinion, you shouldn't have to check if a particular repository you (as a program with given set of features implemented) happen to be looking at has tags in order to decide what capabilities to advertise.

> 2. Client sends space separated list of capabilities it wants. It SHOULD
>    (or perhaps it is MAY?) send subset of server capabilities, i.e do
>    not send capabilities served does not advertise.

I'd say "the client SHOULD NOT ask for capabilities the server did not say it supports".

> 3. Server MUST ignore capabilities it does not understand. Server MUST
>    NOT ignore capabilities (or SHOULD NOT only?) that client requested
>    and server advertised.

I know unrecognized capability requests are silently ignored, but I consider that as a sloppy/practical programming, and not a specification.