I've never used the `pre-commit` framework, but it's really simple to wire up arbitrary shell scripts; check out the

`.git/hooks` directory in your repo for samples, e.g. `.git/hooks/pre-commit.sample`.

You can run any old shell script there, without having to install a python tool.

Yeah but that githook will only be installed on that one repo on that one machine. And they may have no or a different version of bash installed (on e.g. MacOS or Windows). IMHO, POSIX-compatible portable shell scripts are more trouble than portable Python scripts.

Pre-commit requires Python and pre-commit to be installed (and then it downloads every hook function).

This fetches the latest version of every hook defined in the .pre-commit-config.yml:

  pre-commit autoupdate

https://pre-commit.com/#pre-commit-autoupdate

A person could easily `ln -s repo/.hooks/hook*.sh repo/.git/hooks/` after every git clone.

Out of curiosity, Is there value in doing this over (say) running a GitHub Action post commit and failing the build if it finds something nasty?

If you can catch it before the commit is even made then why do/wait for a build?

Fair enough. Guess IDE plugins work even better for that

IDE plugins are not at all consistent from one IDE to another. Pre-commit is great for teams with different IDEs because all everyone needs to do is:

  [pip,] install pre-commit
  pre-commit install
  # git commit
  #   pre-commit run --all-files

  # pre-commit autoupdate

https://pre-commit.com/