zlacker

Git hooks are like make files for me. Copy/paste that `git staged files` command and then add your linter commands (in .githooks/pre-commit file). Add `set -e`. Set package manager post-install hook to config git to the `.githooks` dir.

Sadly I think git hook managers remove the simplicity of the whole design. Understandably since no one reads manuals anymore and projects don’t mind tacking on yet another module/plugin, however easy.

>>righth+(OP)
I can get behind a hook manager that's a single binary. Where I have an issue is with (for instance) python hook managers where you now need to have python interpreter management that's aware of both the python app you're working on, and the tooling which might have a non-intersecting version requirement.

>>regula+g2
While I understand your valid criticism with the overhead of using an interpreted language here, I must point out that using multiple versions in the same repository is quite an antipattern that comes with various complications. Maybe you should consider switching to a version manager of[0] your[1] choice[2].

[0]: https://github.com/jdx/mise

[1]: https://github.com/asdf-vm/asdf

[2]: https://github.com/version-fox/vfox

>>righth+(OP)
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.

>>righth+(OP)
100%, I was using husky because we were using it at work. But it turns out for my use-case all I needed was this in my package.json:

    "scripts": {
        "postinstall": "git config --local core.hooksPath etc/hooks"
    },

>>cowsan+V9
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+V9
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.

>>righth+(OP)
Sometimes I wonder if the death of blogging - which in turn killed a lot of showing people how to use a tool where they’d otherwise skip the manual - means we entered a world where people jump immediately to building a tool for an otherwise simple concept.

>>warp+Xb
Ooh, core.hooksPath is quite nifty. I usually use something like

         ln -sf ../../scripts/git-pre-commit-hook .git/hooks/pre-commit

which simply adds a pre-commit symlink to a script in the repo's scripts/ dir. But hooksPath seems better.

>>cowsan+V9
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.

>>whilen+S4
You have misunderstood my criticism. I don't care in the slightest about the interpreter overhead. I care that I am forced into needing multiple versions in the same repository by having one version required by (for instance) a hook manager, and a different version required by the project itself. I am already using a version manager; it doesn't solve that problem.

>>what+E01
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.