On 15.09.16 22:04, Junio C Hamano wrote: > Lars Schneider <larsxschneider@xxxxxxxxx> 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" [1]. > > 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: --- a/Documentation/technical/protocol-common.txt +++ b/Documentation/technical/protocol-common.txt @@ -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. +