On 15.09.16 22:04, Junio C Hamano wrote:
> Lars Schneider <larsxschnei...@gmail.com> writes:
>> Wouldn't that complicate the pathname parsing on the filter side?
>> Can't we just define in our filter protocol documentation that our
>> "pathname" packet _always_ has a trailing "\n"? That would mean the
>> receiver would know a packet "pathname=ABC\n\n" encodes the path
>> "ABC\n" .
> That's fine, too. If you declare that pathname over the protocol is
> a binary thing, you can also define that the packet does not have
> the terminating \n, i.e. the example encodes the path "ABC\n\n",
> which is also OK ;-)
> As long as the rule is clearly documented, easy for filter
> implementors to follow it, and hard for them to get it wrong, I'd be
> perfectly happy.
(Sorry for the late reply)
In V8 the additional "\n" is clearly documented.
On the long run,
I would suggest to be more clear what BINARY is:
@@ -61,6 +61,9 @@ the length's hexadecimal representation.
A pkt-line MAY contain binary data, so implementors MUST ensure
pkt-line parsing/formatting routines are 8-bit clean.
+Each pkt-line that may contain ASCII control characters should
+be treated as binary.