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. >> +`run_hook_complex`:: Also, I think the updated interface should become the "run_hook" function; nothing "complex" about it. The name "run_hook()" was a perfectly fine abstraction for what it did when it used to be a static helper function within builtin-commit.c, but its special-casing of GIT_INDEX_FILE environment is _not_ general enough to deserve it to be called the "run_hook" in the global scope. IOW, I am saying that we screwed up at ae98a00 (Move run_hook() from builtin-commit.c into run-command.c (libgit), 2009-01-16. The environment tweaking should not take a "index_file" field in the structure, but an array "environ" that is used to tweak the environment variables for the hook process. -- 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