Re: [PATCH v4 11/12] convert: add filter.<driver>.process option
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 5, 2016, 22:06 UTC
- Message-ID
- <xmqqfuqivpjv.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <2e13c31c-5ee2-890d-1268-98fb67aba1ea@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
Show 10 quoted lines
> On 2016-08-03 18.42, larsxschneider@gmail.com wrote: >> The filter is expected to respond with the result content in zero >> or more pkt-line packets and a flush packet at the end. Finally, a >> "result=success" packet is expected if everything went well. >> ------------------------ >> packet: git< SMUDGED_CONTENT >> packet: git< 0000 >> packet: git< result=success\n >> ------------------------ > I would really send the diagnostics/return codes before the content.
I smell the assumption "by the time the filter starts output, it must have finished everything and knows both size and the status".
I'd prefer to have a protocol that allows us to do streaming I/O on both ends when possible, even if the initial version of the filters (and the code that sits on the Git side) hold everything in-core before starting to talk.
Show 14 quoted lines
>> If the result content is empty then the filter is expected to respond >> only with a flush packet and a "result=success" packet. > ... > Which may be: > > packet: git< result=success\n > packet: git< SMUDGED_CONTENT > packet: git< 0000 > > or for an empty file: > > packet: git< result=success\n > packet: git< SMUDGED_CONTENT > packet: git< 0000
The above two look the same to me.