In a non-interactive environment, git commit doesn't work

In a non-interactive git environment (like Visual Studio Code), the git hook hangs while waiting for input from the user.

I’ve installed gitlint v0.15.0 on OpenSuse in WSL and added it to my repo using install-hook with a default config file using generate-config. However, if I want to commit in Visual Studio Code (using the Remote - WSL extension), the commit process hangs if there’s something wrong with my commit message. The only way to proceed is by killing the script

The output

> gitlint --staged --msg-filename "$1" run-hook
> git config --get-all user.name
> git config --get-all user.email
> git -c user.useConfigOnly=true commit --quiet --allow-empty-message --file -
> git ls-files --stage -- /home/phillip/src/100-days-of-code/.gitlint
> git cat-file -s 317c4136f08cafaeb8f577a043aa4291684e6424
> git show --textconv :.gitlint
gitlint: checking commit message...
-----------------------------------------------
gitlint: Your commit message contains the above violations.
Continue with commit anyways (this keeps the current commit message)? [y(es)/n(no)/e(dit)] .git/hooks/commit-msg: line 22:  5628 Terminated 

I hoped that adding --silent and --ignore-stdin to the commit hook would help but unfortunately it did not.

[jorisroovers]

Ok, most obvious question first (just so we can rule it out): did you actually try to answer the question (y/n/e), or is the prompt not interactive at all?

Secondly, I think our focus on the --ignore-stdin might be taking us in the wrong direction, although the confusion is understandable.

We’re conflating gitlint’s --ignore-stdin general option with enabling/disabling the interactive gitlint commit-msg hook prompt. Those are 2 different things, although both have to do with stdin and TTYs.

Consider these examples of --ignore-stdin:

# This will lint "foobar" as a commit message, using the interactive hook
# Because the stdin = pipe (i.e. not interactive), this will abort immediately after the first user-prompt
echo "foobar" | gitlint run-hook

# This will force gitlint to ignore the piped input "foobar", and just lint the last commit message
# Note however that because stdin = (pipe i.e. not interactive), gitlint will still abort after the first user-prompt
# We might debate whether this is expected behavior
echo "foobar" | gitlint --ignore-stdin run-hook

Normally, Python’s input() is what causes the abort to happen if stdin is non-interactive. But clearly that’s not happening in your case (i.e. why I asked whether it’s definitely not possible to just answer y/n/e on the prompt in VSCode). https://github.com/jorisroovers/gitlint/blob/e06dfe02c222b1d4807c17b9c534d7deeed7a8e6/gitlint/cli.py#L386

Ideally, we should be able to detect this scenario reliably, but from experience I know that introducing a ‘force ignore’ option is not a bad idea so we always have a work-around. However, if we do this, I think it should be an option specific to run-hook and not re-use the generic --ignore-stdin option that already has a different meaning. Something like --non-interactive:

# Note that `--non-interactive` is specified *after* `run-hook`, and not before like `--ignore-stdin`
gitlint run-hook --non-interactive

# This will still work and lint "foobar", but the hook will be forced to be non-interactive
echo "foobar" | gitlint run-hook --non-interactive

--non-interactive could then also be set using a .gitlint option hook-non-interactive=True and env var GITLINT_HOOK_NON_INTERACTIVE=1.

Of course, because it’s a force flagm it means the hook will always be non-interactive, even when you invoke it from a regular CLI.

PS: christmas time 🎄 , so delayed responses are very likely. I suggest not spending/wasting too much time on PRs on this until we’ve figured out the approach first. Thanks for your help!

[eugen1j]

I came up with custom commit-msg git hook like this

gitlint --msg-filename $1