Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2015, 18:06 UTC
Message-ID: <xmqq7fqd17qn.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAD0k6qRGQyFxZ8+yqkzYff_k4ZjWPaegQbBphwXyfBtUOCCw6g@mail.gmail.com>

Dave Borowitz <dborowitz@google.com> writes:

Show 17 quoted lines

> On Mon, Jul 6, 2015 at 1:34 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Dave Borowitz <dborowitz@google.com> writes:
>>
>>> Another way of looking at the problem with my assumptions is, I was
>>> assuming "pkt-line framing" was the same thing as "pkt-line header".
>>> You seem to be saying the definition of "pkt-line framing" is "header,
>>> and optional trailing newline".
>>
>> Yes.  I thought that was what "Server SHOULD terminate with LF;
>> client MUST NOT require it" in the existing text meant.
>
> Unfortunately, the existing text is littered with examples of
> "PKT-LINE(foo SP bar LF)". If we assume "PKT-LINE(...)" means "apply
> pkt-line framing to the [...]", then this strongly implies that
> "pkt-line framing" does _not_ include the trailing LF. (Or the logical
> but bizarre alternative reading that such an example might have _two_
> trailing LFs :)

Yes, But I never viewed PKT-LINE() as an element that strictly defines the grammar of the packet protocol ;-)

By clarifying that "sender SHOULD terminate with LF, receiver MUST NOT require it" is the rule (and fixing the existing implementations at places where they violate the "MUST NOT" part, which I think are very small number of places), I think we can drop these LF (or LF? for that matter) from all of the PKT-LINE() in the construction in the pack-protocol.txt, which would be a very good thing to do.

The example in your sentence will become PKT-LINE(foo SP bar) and the "there may be an LF at the end" would only be at one place, as a part of the definition of PKT-LINE().