zlacker

The big difference with Makefiles is that git hooks can’t be committed to the repo. Hook managers allow hooks to be shared and updated across a team.

>>cowsan+(OP)
Committing git hooks to the repo is possible. These are the 2 ways in which they're commonly handled:

1. Link the scripts from the worktree to the .git/hooks directory - perhaps using a bootstrap script.

Ref: https://codeinthehole.com/tips/tips-for-using-a-git-pre-comm...

2. Declare the directory in the worktree to be the local git hooks directory.

Ref: https://knpw.rs/blog/direnv-git-hooks

>>cowsan+(OP)
So do dev-environment start-up scripts, which in my experience are always simpler, clearer, and more maintainable than these managers.

Just put your hook logic in a script and copy it to the git hooks folder on startup as necessary -- and then, voila, you've avoided the nonsense of some well-intentioned package whose author thinks Rust in git hooks is a selling point rather than a head scratcher.

>>cowsan+(OP)
Hooks shouldn’t be shared and updated across a team. Don’t force your workflow on others. Which is exactly why you can’t or shouldn’t commit them.

>>what+JQ
What is the technical justification behind such as statement? Sharing hooks across the team doesn't equate to forcing a workflow on them. Each developer must manually activate the hooks in some manner in all the cases I've seen. Otherwise, they work as usual without the hooks and without interfering in the workflow in any manner. As a corollary, the hook conditions are enforced in the CI (since it can't be enforced in the developer's system). Git hooks are instead offered as a convenience function to help the developers catch mistakes early and often, before it hits the CI.