On Tue, Jan 03, 2012 at 11:53:22AM -0800, Junio C Hamano wrote: > Johannes Sixt <j6t@xxxxxxxx> writes: > > > IMO, as the first step, the user of this infrastructure should only be > > required to construct the hook input as a strbuf, and receive the hook > > output, if needed, also as a strbuf. > > Now you brought it up, I think I would agree. The only reason I suggested > a callback feeder approach was because I somehow was hoping that it may be > possible to share more code with the codepath for textconv that may not > want to hold too much buffer in core when we know the data is only used > sequencially and I wanted to see more things to go through streaming API > in the future. Even if we don't make the input streaming, it would be nice to factor the concept of "feed input to program and read its output without deadlocking" into something independent of hooks. The credential helper code could potentially have the same deadlock. Possibly also clean/smudge filters. Maybe it could even be part of the run-command interface? -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