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

>
> Dave Borowitz <dborowitz@google.com> writes:
>
> >> I am moderately negative about this; wouldn't it make the end result
> >> cleaner to fix the implementation?
> >
> > I'm not sure I understand your suggestion. Are you saying, you would
> > prefer to make LFs optional in the push cert, for consistency with LFs
> > being optional elsewhere?
>
> Absolutely.  It is not "make" it optional, but "even though it is
> optional, the receiver has not been following the spec, and it is
> not too late to fix it".
>
> The earliest these documentation updates can hit the public is 2.6;
> by that time I'd expect the deployed receivers would be fixed with
> 2.5.1 and 2.4.7 maintenance releases.
>
> If some third-party reimplemented their client not to terminate
> with LF, they wouldn't be working correctly with the deployed
> servers right now *anyway*.  And with the more lenient receive-pack
> in 2.5.1 or 2.4.7, they will start working.
>
> And we will not change our client to drop LF termination.  So
> overall I do not see that it is too much a price to pay for
> consistency across the protocol.

> > If LF is optional, then with that approach you might end up with a
> > section of that buffer like:
>
> I think I touched on this in my previous message.  You cannot send
> an empty line anywhere, and this is not limited to push-cert section
> of the protocol.  Strictly speaking, the wire level allows it, but I
> do not think the deployed client APIs easily lets you deal with it.
>
> So you must follow the "SHOULD terminate with LF" for an empty line,
> even when you choose to ignore the "SHOULD" in most other places.
>
> I do not think it is such a big loss, as long as it is properly
> documented.