To entice people who are fluent in said language, or those who are looking for something compiled and performant. If I see a project written in (java|type)script, I know to avoid it.

But no one forces pre-commit hooks onto you? You can just not install the hook into git and run the tool manually instead.

Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing.

Now, if the server enforces checks on push, that's a project policy that should be respected.

I use exactly one such hook, and that's to add commit signoff because of a checklist-compliance item called DCO that fails all PRs unless they have the sign-off trailer added by `git commit -s`. I've long argued that we should be enforcing actual signed commits instead, but compliance has never been about doing the sensible thing.

It's as simple as a script with a cp command that I run after any clone of a repo that requires it; certainly doesn't require anything as elaborate as a hook manager.

Voting and comment rings are against HN guidelines

> they … aren’t compatible with commits that leave unstaged files in your tree.

It's a little surprising that git doesn't pass pre-commit hooks any information, like a list of which files were changed in the soon-to-be-made commit. git does so for pre-push, where it writes to a hook's stdin some information about the refs and remotes involved in the push.

I wonder if many pre-commit hooks, like the kind which run formatters, would be better off as `clean` filters, which run on files when they are staged. The filter mechanism makes it easier to apply just to the files which were changed. In the git docs, they even use a formatter (`indent`) as an example.

https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attribute...

I leave unstaged files all the time, not sure what you mean.