Shawn Pearce <spea...@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.
--
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
