Re: [PATCH v7 10/10] convert: add filter.<driver>.process option
- From
Torsten Bögershausen <tboegi@web.de>
- Date
- Sep 29, 2016, 06:33 UTC
- Message-ID
- <30461d2d-5a9c-4b0c-25a0-aa3327622764@web.de>
- In-Reply-To
- <xmqq37l1nd42.fsf@gitster.mtv.corp.google.com>
On 15.09.16 22:04, Junio C Hamano wrote:
Show 17 quoted lines
> Lars Schneider <larsxschneider@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" [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. +