Commit hooks requiring user input - how to handle?

[gedkott]

I have a pre-commit hook that asks a few questions to the committer prior to running the rest of the standard commit hooks (those not requiring user input). When I attempt to commit, the script that gather user input starts, prints out some chunk of the prompt and then exits. I tried to track this down and see why and it appears that the 'close' event on the spawned process is getting called earlier than I would expect on the user-input-expecting hook AKA almost immediately after printing the first prompt it emits a 'close' event on the spawned process. This causes 'again' to be called unexpectedly. I need to find out why that is happening. I had the same issue with the readline module and the prompt module. Maybe it is how user prompting works generally?
My question is: Is requesting user input and waiting on it before continuing on to the next hook not a feature we want to support or is it bad practice to ask for user input during a hook? I would like to make it possible, but just wanted to see some opinions on this.

[joseph-galindo]

This is not an issue really with this npm package, but a design decision on git's part to not use standard input when processing hooks. The idea is that a hook should be able to run without user interaction. For example, how would a server running automated jobs handle the pre-receive hook if it needed user input?

That being said, for a client-side hook like pre-commit, it seems like you can get around this by explicitly pointing to a terminal's input, which is fine as long as you can guarantee a terminal is there to read input from.