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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Dave Borowitz <dborowitz@xxxxxxxxxx> 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.

Ok, I understand your proposal now, thank you. I will drop this
documentation patch from this series, and abandon
https://git.eclipse.org/r/51071 in JGit. I am not volunteering to
rewrite push cert handling in git-core though ;)

> > 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]