I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?

Many projects have used "hook managers" like Husky for this to install hooks to run based on repository-stored metadata.

These new config-based hooks are definitely a step down the road towards obsoleting the third-party hook managers. One of the things they are for is for managing scripts to support multiple hooks for the same event. The new config format supports multiple hooks for the same event natively. (Which also helps in stacking personal ones versus repository ones.)

The only thing missing is that the repository's .git/config isn't itself source controlled in that repository, so for now there would still be an "install step", but it's now a lot simpler of an "install step" with the install being "append .example-gitconfig into your .git/config" rather than "set X files to X different contents in .git/hooks/*" where X is the number of event hooks to be concerned about.

It does open the door further to if there should be a ".gitconfig" in the Repository working tree that can also contribute repository-wide shared config, what config it can or cannot contribute, and how you secure that as a reviewable opt-in (especially change notifications). But a smartly built secure UX there would be a massive improvement over, say, shell scripts in npm postinstall operations touching .git/hooks "for you" (which is how many of the current hook managers auto-install, as side effects in dependency installs).

(ETA: Though most "install scripts" now just use the very scriptable `git config` command and so just be `git config set --local hook.$name.$field $value` sequences, which is also a simpler improvement over previous ways to install and/or merge hooks files by hooks managers.)

> 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.

I wish that git would auto check for a `.githooks` directory in the repo root and prompt on first clone if the `core.hooksPath` should be changed for this repositry and when pulling any tracked file in hooksPath causes a warning (though this still leaves out the case that some hook just invokes a script in the repo outside the dir).

I don't want you to run arbitrary hooks on my machine. As with CI/CD... your hooks should simply point to a script instead

I always considered hooks a nice to have feature for devs to already validate that their PRs will probably satisfy certain CI checks. If they don't install or run them for whatever reason, it's on them to do another iteration and update the code to make it mergeable if CI complains. So I usually considered it fine that they are only opt-in, since the merge will be gated by a CI outside of the dev's control anyway.

Adding configuration to the config makes things feel far less exotic. I think these changes certainly improve things, but there's still plenty of room to go further.

I think there should probably be a way to specify canonical git configuration for things like hooks and LFS and all of that. It would be nice if when you clone, git prompts you to trust the remote config or to ask you to accept each new change as they come or fully reject them.

Having to scrape through the readme of every repo and then run arbitrary scripts doesn't seem like the most secure solution. When there's a canonical flow gitlab GitHub and all the tooling can support it and have proper permissions around it.

It's really disappointing how much lack of empathy there is when talking about new git features. Forget empathy. There's outright disdain for discussing alternative workflows.

In PHP, an established tool is adding GrumPHP [0] to your dependencies.

It will then handle git hooks on each commit via composer script by default (but can be omitted per commit).

[0] https://github.com/phpro/grumphp

The approach some JS projects have taken is to use Husky, which automatically sets up the git hooks when you install the project's dependencies during development.

I agree with the other replies saying to just run the checks in CI and have the CI error message mention how to install the pre-commit hook.

I'm glad cloning a repo doesn't automatically install hooks since I strongly dislike them: I often use Git commands in the terminal but sometimes I use the VS Code UI to commit, and it's extremely frustrating when simply creating a commit runs for several seconds because of some pre-commit hook.

I add an autogen.sh script to all my repositories that does things like this as it's first action.

My project needs other things on setup as well, so I just have a setup script in my repo. `mv hooks/foo .git/hooks` is then just yet another step.