On Mon, Apr 08, 2013 at 07:13:11PM +0100, Adam Spiers wrote: > I was recently informed by the author of git-annex that my > implementation of git check-ignore has two minor deficiencies which > currently prevent him from adding .gitignore support to the git-annex > assistant (web UI): > > 1. When accepting a list of files to check via --stdin, no results > are calculated until EOF is hit. This prevents it being used > as a persistent background query process which streams results > to its caller. (This is inconsistent with check-attr, which > *does* support stream-like behaviour.) I think flushing on each line is reasonable, though you are also introducing a deadlock possibility for callers which do not read back the output in real-time. For example, if I write N paths out then read N ignore-lines back in, I risk a situation where I am blocked on write() to check-ignore, and it is blocked on write back to me. Somebody has to buffer (the pipe buffers give you some leeway, but they are limited). Given how new check-ignore is, and that we have not advertised any particular buffering scheme so far, it's probably OK to switch without worrying about breaking existing callers. But if this is a mode of operation that we expect people to use (here and for check-attr), we should advertise the flushing behavior, and probably warn about the deadlock (I don't think adding a "--no-flush" option is worth it, as it would just mean buffering in check-ignore, which the caller could just as easily do itself). -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