Re: [PATCH v4 1/2] hooks: allow input from stdin for commit-related hooks

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Nov 19, 2020, 21:23 UTC
Message-ID: <CAPig+cSN=-7KWgDcXM8po44PEKi27U6mJEEL0mj_wrTJBUf=WA@mail.gmail.com>
In-Reply-To: <3bd6024a236b061c89bb6b60daf3dc15ef1e32ca.1605819390.git.gitgitgadget@gmail.com>

On Thu, Nov 19, 2020 at 3:57 PM Orgad Shaneh via GitGitGadget <gitgitgadget@gmail.com> wrote:

Show 8 quoted lines

> Let hooks receive user input if applicable.
> [...]
> This allows for example prompting the user to choose an issue
> in prepare-commit-msg, and add "Fixes #123" to the commit message.
>
> Another possible use-case is running sanity test on pre-commit,
> and having a prompt like "This and that issue were found in your
> changes. Are you sure you want to commit? [Y/N]".

These use-cases really help readers understand the motivation for this change. Good.

Show 6 quoted lines

> Allow stdin only for commit-related hooks. Some of the other
> hooks pass their own input to the hook, so don't change them.
>
> Note: If pre-commit reads from stdin, and git commit is executed
> with -F - (read message from stdin), the message is not read
> correctly. This is fixed in the follow-up commit.

Rather than making such a fundamental change and having to deal with the fallout by introducing complexity to handle various special-cases which pop up now and in the future, I wonder if it makes more sense to instead just update documentation to tell hook authors to read explicitly from the console rather than expecting stdin to be available (since stdin may already be consumed for other purposes when dealing with hooks or commands which invoke the hooks).