"Orgad Shaneh via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > From: Orgad Shaneh <orgads@xxxxxxxxx> > > Let hooks receive user input if applicable. > > Closing stdin originates in f5bbc3225 (Port git commit to C, > 2007). Looks like the original shell implementation did have > stdin open. Not clear why the author chose to close it on > the C port (maybe copy&paste). For "git commit" leaving the standard input open and let hook interact with the end-user sitting at the terminal might be OK, but doing this for any and all hooks probably breaks callers of hooks that deal with transport protocols where their standard input is *not* supposed to be molested (think: the main Git process is about to read a packstream over the network and spawns a hook using the standard run_hook*() interface---if the hook reads standard input, the main process would lose the initial part of the pack stream). > The only hook that passes internal information to the hook > via stdin is pre-push, which has its own logic. Hmph, doesn't "pre-receive" hook gets information from its standard input? In any case, it is natural that such hooks can and have to be able to read from their standard input---they are spawned with their input connected to Git process that feeds them input that are necessary for them to make decision, so comparing them with random other hooks that do not use information from Git to do their thing is comparing apples and oranges. So I think the patch we see as-is is probably not a good idea, primarily because it lets run_hook_ve() to pretend that it still is a generic interface to run any hooks by sitting in run_command.c, but now its behaviour has been tweaked to fit only needs by "git commit" and the like. You probably need to add a new "options" parameter to run_hook_ve() that allows the callers to say "this hook is allowed to read from the standard input" etc., if we want to keep it in run_command.c and let it pretend to be generally useful interface. Another possibility is to remove run_hook_ve(), and open code its body in commit.c::run_commit_hook(), but that is less than ideal. > Some references of users requesting this feature. Some of > them use acrobatics to gain access to stdin: > [1] https://stackoverflow.com/q/1067874/764870 > [2] https://stackoverflow.com/q/47477766/764870 > [3] https://stackoverflow.com/q/3417896/764870 > [4] https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3165 > [5] https://github.com/typicode/husky/issues/442 Instead of wasting 7 lines here, it would be a much better approach to just add a test or two that demonstrate sample usages and that protect this new feature from accidentally getting broken at the same time. > The only hook that passes internal information to the hook via stdin is > pre-push, which has its own logic. > > Some references of users requesting this feature. Some of them use > acrobatics to gain access to stdin: [1] > https://stackoverflow.com/q/1067874/764870[2] > https://stackoverflow.com/q/47477766/764870[3] > https://stackoverflow.com/q/3417896/764870[4] > https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/3165[5] > https://github.com/typicode/husky/issues/442 > > Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-790%2Forgads%2Fhooks-stdin-v1 > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-790/orgads/hooks-stdin-v1 > Pull-Request: https://github.com/gitgitgadget/git/pull/790 > > run-command.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/run-command.c b/run-command.c > index 2ee59acdc8..a17b613216 100644 > --- a/run-command.c > +++ b/run-command.c > @@ -1356,7 +1356,6 @@ int run_hook_ve(const char *const *env, const char *name, va_list args) > while ((p = va_arg(args, const char *))) > strvec_push(&hook.args, p); > hook.env = env; > - hook.no_stdin = 1; > hook.stdout_to_stderr = 1; > hook.trace2_hook_name = name; > > > base-commit: e31aba42fb12bdeb0f850829e008e1e3f43af500
