-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In a non-interactive environment, git commit doesn't work #171
Comments
Hi Phillip, nice to see you here :-) Interesting case, since I have tested this on VScode on Mac when rewriting the commit-msg hook recently (ced7bde and #157). I think this might be related to WSL + Remote extension - I've never used those. My gut reaction is the root-cause is probably related to either:
Thanks! |
Hi Joris 😃 . Glad I can finally try out gitlint ... If I get the hang of it I might introduce it at work. Verified that it was running with the correct arguments using This is the output from the git log in VSCode
I've been looking at the code and it seems like the --ignore-stdin isn't checked here: https://github.com/jorisroovers/gitlint/blob/main/gitlint/cli.py#L371 I tried hard-coding I can try to make a pull request but I'm not exactly a seasoned Python developer 😄 |
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 We're conflating gitlint's Consider these examples of # 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 Line 386 in e06dfe0
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 # 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
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! |
I want to introduce gitlint at work project. I'm going to insert checks in CI pipeline and pre-commit hook. There is an option to skip checks in pre-commit hook: It seems, that new
Did you figure out is this approach is good enough? In this case I can try to send a PR for this feature. |
I came up with custom
|
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
I hoped that adding --silent and --ignore-stdin to the commit hook would help but unfortunately it did not.
The text was updated successfully, but these errors were encountered: