Torsten Bögershausen <tboegi@xxxxxx> writes: > On 2016-08-03 18.42, larsxschneider@xxxxxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html