On Mon, Aug 08, 2016 at 06:21:18PM +0200, Lars Schneider wrote: > >> Happy answer with no content: > >> ------------------------ > >> packet: git< status=success\n > >> ------------------------ > > > > This can just be spelled: > > > > git< status=success > > git< 0000 > > git< 0000 # empty content! > > git< 0000 # empty list! > > Is the first flush packet one too many? > If there is nothing then I think we shouldn't > send any packets?! > > I agree with the remaining two flush packets. There isn't nothing, there is a "status" field (though I think that should probably be required, so I guess you could imagine it as a stand-alone pkt, separate from the list terminated by the flush). But regardless, you need the first flush to say "I am done telling you up-front keys, now I am starting the content". Otherwise, what would: git< status=success git< foo=bar git< 0000 be parsed as? Is "foo=bar" the first line of content, or the rest of the pre-content header? (You could guess if you could see the total conversation, but you can't; you have to parse it as it comes). > There is one more thing: I introduced a return value "status=error-all". > Using this the filter can signal Git that it does not want to process > any other file using the particular command. > > Jakub came up with this idea here: > > "Another response, which I think should be standarized, or at > least described in the documentation, is filter driver refusing > to filter further (e.g. git-LFS and network is down), to be not > restarted by Git." > > http://public-inbox.org/git/607c07fe-5b6f-fd67-13e1-705020c267ee%40gmail.com/ > > I think it is a good idea. Do you see arguments against it? No, that seems reasonable (I would have just implemented that by hanging up the connection, but explicitly communicating is more robust). -Peff -- 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