I feel like I found better git commands for this, that don't have these problems. It's not perfect, sure, but works for me.<p>The pre commit script (<a href="https://github.com/ThomasHabets/rustradio/blob/main/extra/pre-commit" rel="nofollow">https://github.com/ThomasHabets/rustradio/blob/main/extra/pr...</a>) triggers my executor which sets up the pre commit environment like so: <a href="https://github.com/ThomasHabets/rustradio/blob/main/tickbox/precommit/10-setup.sh" rel="nofollow">https://github.com/ThomasHabets/rustradio/blob/main/tickbox/...</a><p>I run this on every commit. Sure, I have probably gone overboard, but it has prevented problems, and I may be too picky about not having a broken HEAD. But if you want to contribute, you don't have to run any pre commit. It'll run on every PR too.<p>I don't send myself PRs, so this works for me.<p>Of course I always welcome suggestions and critique on how to improve my workflow.<p>And least nothing is stateful (well, it caches build artefacts), and aside from "cargo deny" no external deps.
To bring up jujutsu, `jj fix` (<a href="https://docs.jj-vcs.dev/latest/cli-reference/#jj-fix" rel="nofollow">https://docs.jj-vcs.dev/latest/cli-reference/#jj-fix</a>) is a more refined way of ensuring formatting in commits. It runs a formatting command with the diff in stdin and uses the results printed to stdout. It can simplify merges and rebases history to ensure all your commits remain formatted (so if you enable a new formatting option, it can remove the need for a special format/style fix commit in your mutable set). Hard to go back to pre-commit hooks after using jj fix (also hard to use git after using jj ;) ).
I’ve seen similar issues once hooks start doing more than fast checks. The moment they become stateful or depend on external context, they stop being guardrails and start being a source of friction. In practice, keeping them boring and deterministic seems to matter more than catching everything early.
This was a really interesting read. I'd highly recommend it for anybody who's setting up (or currently maintains) a pre-commit workflow for their developers.<p>I want to add one other note: in any large organization, some developers will use tools in ways nobody can predict. This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.<p>Instead, put what you want in an optional pre-push hook and also put it into an early CI/CD step for your pull request checker. You'll get the same end result but your fussiest developers will be happier.
> This includes Git. Don't try to force any particular workflow, including mandatory or automatically-enabled hooks.<p>And with git, you can even make anything that happens on the dev machines mandatory.<p>Anything you want to be mandatory needs to go into your CI. Pre-commit and pre-push hooks are just there to lower CI churn, not to guarantee anything.<p>(With the exception of people accidentally pushing secrets. The CI is too late for that, and a pre-push hook is a good idea.)
I can second that. If there are multiple commits: <a href="https://github.com/tummychow/git-absorb" rel="nofollow">https://github.com/tummychow/git-absorb</a> is handy to add formatting changes into the right commit after commits already happened.
Your hook can't observe a simple env var, if you are stepping off the happy path of your workflow? E.g. `GIT_HOOK_BYEBYE` = early return in hook script. Article seems a little dramatic. If you write a pre-commit hook that is a pain in your own arse, how does that make them fundamentally broken?
Thank you. I don't need to "fix" a commit before it ends up on a remote branch. Sometimes I expect a commit to pass checks and sometimes I don't. Frankly, don't even run pre-push hooks. Just run the checks in CI when I push. You'd better be doing that anyway before I'm allowed to push to a production branch, so stop breaking my git workflows and save me the time of running duplicate checks locally.<p>Also, if most developers are using one editor, configure that editor to run format and auto-fix lint errors. That probably cleans up the majority of unexpected CI failures.
Pre-commit and pre-push hooks are something developers can voluntarily add (or enable) to shorten the latency until they get feedback: instead of the CI rejecting their PR, they can (optionally!) get a local message about it.<p>Otherwise, I agree, your project can not rely on any checks running on the dev machine with git.
A bit less enraged: pre-commit hooks should be pure functions. They must not mutate the files being committed. At best, they should generate a report. At worst, they could reject a commit (e.g. if it contains a private key file included by mistake).
Yep, all that and they’re also annoying. Version control tools are not supposed to argue - do what you’re told. If I messed up, the branch build will tell me.