Summary

There is one very common mistake people would make when running system hook entries as is related to the natural impression that these hooks will all run using SHELL.

Here are few facts that would describe why is quite common to write system hooks that would only fail on some platform on when triggered by specific tools (like your visual git client), basically creating unreliable / unpredictable hooks.

• entry: foo || bar && zzz seems to be working, so people assume shell commands are fine...
• entry: bash -c '...' seems legit too... until you realize that user shell might be different one (zsh) and that bash would not have access the same tools (mise, asdf, pyenv and so on...).

I my particular case I had something like entry: uv run --group lint mypy which worked for most cases but it failed with Fork git client when pushing it, despite configuring Fork to start a shell to run the commands.

Workaround so far seems to be entry: sh -c '...' as this seems to be working good on both macos and linux and also with various clients, mainly because sh is almost starting the default user shell on each platform, effective one being dash on Ubuntu, zsh on MacOS and likely bash on other Linux platforms.

The issue that the extra boilerplate make hook definitions more complex as it will likely also require extra escapes.

Can we do something to avoid the need for this wrapper, like making prek do this by default? -- as this might cause some unexpected behaviors, maybe we can add this a a top level configurable option, especially as this would allow to 'fix' behavior hooks defined and maintained by others?

Willing to submit a PR?

• Yes — I’m willing to open a PR to fix this.

Platform

Version

.pre-commit-config.yaml

Log file