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, 16:28 UTC
Message-ID: <xmqqfv512qu9.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAJo=hJvfYfgBthFMYXnXJ6e6PVM92SsWGVNt7qNTSQH9=psGtQ@mail.gmail.com>

Shawn Pearce <spearce@spearce.org> writes:

> push cert format is like commit or tag format. You need those LFs. We
> can't just go declare them optional because of the way pkt-line read
> function is implemented in git-core.

As I said, I view each of the packets between "push-cert" and "push-cert-end" packets representing the meat of each line in the cert. The sending end takes a cert as a long multi-line string, splits them into an array, each of whose element represents a line in it (iow "certlines = certstring.split('\n')"), and sends them packetised.

The receiver receives a sequence of packets, notices "push-cert" packet, collects packets until it sees "push-cert-end" packet and treats them as elements of this array. pkt-line deframing process would have to strip optional LFs to reconstruct the original array the sender had (i.e. the above certlines array).

The receiver needs to join the array with LF to recover the long multi-line string once it received the array. But this LF does not have anything to do with the optional trailing LF in pkt-line. If you sent the original "certlines" array via different RPC mechanism, you need to join them together with your own LF to reconstruct the multi-line srring.