On Wed, Jul 1, 2015 at 4:49 PM, Junio C Hamano <gits...@pobox.com> wrote: > > Dave Borowitz <dborow...@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.
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
