> what workflows have worked best for you to get everyone to run the hooks
By running the linters and any other checks on CI instead.
By running the linters and any other checks on CI instead.
CI should also run all the checks but CI checks are not a replacement for local hooks. LFS and things like it can't be implemented as remote CI checks.
Why are we acting like a James Bond villain, slowly lowering the changes into the vat of sharks after we've left the room? I want the hooks. Can we talk about making that easy, assuming some people want them?
Because we want to be sure that the checks have passed, and that they have passed in a clean environment.
Contributors can, in addition, use git hooks, or run tests in watch mode, or use their IDE.
Also it's annoying to have slow git hooks if you commit often.
Automatically running arbitrary code from random repositories is a Really Bad Idea, so Git will almost certainly never auto-install pre-commit hooks. Just mention it in the README and run a checker in CI to confirm they are using it, it really isn't that difficult.
People wasting 2 minutes of their own time once during their first contribution because they didn't read the README is not that big of a deal. What's next, you want a script to automatically sign a project's legally-binding CLA on checkout?
We already know we're definitely going to run some of these. We know we want to maintain changes to these hooks. Can we stop pretending like we're not doing that? We get it. Some of these will be untrusted so let's design a system to handle that instead of not designing a system and deciding to be just short of as unsafe as possible.
Automation an uniformity increases safety. Human intervention increases human error. Its just a matter of actually finding a good solution to know what is trusted but instead we get "just set it up manually because its safer."
In the other case the repo owner itself is asking it to run pre-vetted code in a controlled sandbox - and only for branches where it is explicitly enabled. It's like running "wc -l", in a sandbox, on mostly-trusted input files.
If one hates the round-trip he/she will adopt hooks quickly.
I was writing more in regards of hooks as "checks" for workflow/lints/etc.
LFS needs an install step and it needed to be brought into git itself to cut through all of the problems. Manually managing hooks is not sufficient.
No amount of "please don't fuck it up" in the readme is going to save you.
Even CI checks for what should and shouldn't look like an lfs stub is non-trivial. I don't think such a thing even exists today.
Signed git plugins and manifest or a canonical way to define hooks in repo that most tools can interface with and allow the user to automatically set up but asks to do so or really so much more.
I don't know why people get fixated on this as if 99.999% of what git pulls down isn't code you expect to run and there are systems in place to protect that.
It's still annoying for new contributors though because they might not know how to set up pre-commit (which was quite a pain until recently because it's written in Python).
All the push back to making this system good just ensures its as terrible as the nay-sayers fear.
Running linters on CI is an antipattern if there was ever one. That and configuring pipeline runs to fail for linting issues.
Sometimes some people just want to create their own problems. Configuring the editor solves most of the problems, and hooks add a failsafe. Once the code is committed, it should be immutable.