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 yo

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