Jeff King <p...@peff.net> writes: > On Sun, Feb 17, 2013 at 05:41:13PM -0800, Jonathan Nieder wrote: > >> > I don't think so. Don't ERR lines appear inside their own packets? >> >> Yes, I misread get_remote_heads for some reason. Thanks for checking. > > Thanks for bringing it up. I had not even thought about ERR at all. So > it was luck rather than skill that I was right. :) > >> I'm not sure whether servers are expected to send a flush after an >> ERR packet. The only codepath I know of in git itself that sends >> such packets is git-daemon, which does not flush after the error (but >> is not used in the stateless-rpc case). http-backend uses HTTP error >> codes for its errors. > > I just checked, and GitHub also does not send flush packets after ERR. > Which makes sense; ERR is supposed to end the conversation.
Hmph. A flush packet was supposed to be a mark to say "all the packets before this one can be buffered and kept without getting passed to write(2), but this and all such buffered data _must_ go on the wire _now_". So in the sense, ERR not followed by a flush may not even have a chance to be seen on the other end, no? That is what the comment before the implementation of packet_flush() is all about. -- 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
