zlacker

[return to "Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust"]
1. candid+6a[view] [source] 2026-02-03 17:10:22
>>fortui+(OP)
I struggle to see value with git hooks. They're an opt-in, easily opt-out way of calling shell scripts from my understanding--you can't force folks to run them, and they don't integrate/display nicely with CI/CD.

Why not just call a shell script directly? How would you use these with a CI/CD platform?

◧◩
2. schind+Ef[view] [source] 2026-02-03 17:33:46
>>candid+6a
This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.
◧◩◪
3. pxc+yc3[view] [source] 2026-02-04 13:15:00
>>schind+Ef
What one considers fast or slow may vary, but the general rule is something like the following.

  - very fast? run it all the time (shell prompt drawing, if you want, like direnv)
  - fast? run it in a pre-commit hook
  - a bit slow? run it in a pre-push book
  - really slow? run it in CI, during code review, etc.
Fwiw: I also rewrite history often-ish but it's never that fast for me because I have commit signing turned on and that requires verifying my presence to a USB smartcard on each commit. For me, it's okay if a commit takes a second or two. As it creeps up beyond 3 or 4 seconds, I become increasingly annoyed. If a commit took a minute I would consider that broken, and if I were expected to tolerate that or it were forced on me, I'd be furious.

I generally expect an individual pre-commit hook to under ~200ms (hopefully less), which seems reasonable to me. Some of the ones we have are kinda slow (more than 1s) and maybe should be moved to pre-push.

Since you seem especially sensitive to that latency, here's what I'd propose if we worked together:

If you own a repo, let's make all the hooks pre-push instead of pre-commit. On my repos, I like many hooks to run pre-commit. But since the hooks we use are managed by a system that honors local overrides via devenv.local.nix, let's make sure that's in .gitignore everywhere. When I'm iterating in your codebases and I want more automated feedback, I'll move more hooks to pre-commit, and when you're working in mine you can move all my hooks to pre-push (or just disable them while tidying up a branch).

[go to top]