On 2016-08-06 00.06, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > >> On 2016-08-03 18.42, larsxschnei...@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. > >>> 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.
-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
