Re: [PATCH v4 11/12] convert: add filter.<driver>.process option

On 2016-08-06 00.06, Junio C Hamano wrote:

Torsten Bögershausen [off-list ref] writes:

quoted

On 2016-08-03 18.42, larsxschneider@gmail.com wrote:

quoted

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.

quoted

quoted

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.

Copy-paste error.
i see that we need a status after the complete transfer,
and after some thinking I would like to take back my comment.