[deleted]
Pre-commit hooks are broken
131–140 of 178 posts
Re: Pre-commit hooks are broken
#132Running on the working tree is mostly okay - just `exit 1` if changes were made and allow the user to stage+commit new changes. It isn't perfect but it doesn't require checking out a new tree.
this completely breaks `git add -p`.
You can either do another `git add -p` after to stage the fixed formatting or do `git add -pn`
Re: Pre-commit hooks are broken
#133Running on the working tree is mostly okay - just `exit 1` if changes were made and allow the user to stage+commit new changes. It isn't perfect but it doesn't require checking out a new tree.
What if I've already fixed the format issue (but not staged it). The pre-commit hook will pass, but it's not doing what the author intended (preventing unformated code from being committed). What if I've only staged one part of a file, but the pre-commit hook fails on the unstaged portions, which should be fine since I'm not commiting or pushing those changes.
You can stash it or `git commit -n`. Perfect is the enemy of good enough.
Re: Pre-commit hooks are broken
#134Home Assistant takes this one step farther. There is a pre-run hook that goes out its way to make it hard to run an “integration” that doesn’t meet its quality standard. I get that they don’t want to get PRs for integrations that don’t check the checklist, but as someone writing an integration (which I’m currently doing, for better or for worse), I want to run my own incomplete integration, thank you very much.
(One very nice thing about AI-assisted programming: Claude is not offended by duplicating the same code over and over and using utterly awful APIs, and Claude feels no particular compulsion to get distracted thinking about how the APIs I’m targeting could be made to be less awful. Try asking the Home Assistant docs how an integration is supposed to handle a hot-added entity after an integration finishes setup: you will not get an answer. Ask Claude and it will cheerfully copy the ludicrous and obviously inappropriate solution used by other integrations. Sometimes semi-blindly doing something that works is the right solution when writing piles of glue code.)
Re: Pre-commit hooks are broken
#135I’ve used pre-commit the tool and now prek for the better part of a decade and never had these issues even using rebase flows exclusively. This seems like an operator error.
Re: Pre-commit hooks are broken
#136Earlier quoted context omitted.
Well, unless you inhibit them with `-n`. Which I would for WIP commits.
Then what’s the point? Just leave them off and run the tests when you want to run them.
Because 99% of my commits are not WIP commits. So I almost always want to run them.
Hell, even most WIP commits will pass the tests (e.g. tests are not yet added for the new code), so I'd run them then too.
Re: Pre-commit hooks are broken
#137I think the examples given in the post are just done poorly. Lefthook with glob+stage_fixed for formatters makes one of the issues raised a complete non-issue. I'll write a in-depth post about it maybe within the next week or so, been diving into these in my hobby projects for a year or so.
My post can be found here: https://news.ycombinator.com/item?id=46409443
Re: Pre-commit hooks are broken
#138This 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. 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. Instead, put what you want in a…
Why not take the best of both worlds?
Use pre-commit hooks for client-side validation, and run the same checks in CI as well.
I’ve been using this setup for years without any issues.
One key requirement in my setup is that every hook is hermetic and idempotent. I don’t use Rust in production, so I can’t comment on it in depth, but for most other languages—from clang-format to swift-format—I always download precompiled binaries from trusted sources (for example, the team’s S3 storage). This ensures that the tools run in a controlled environment and consistently produce the same results.
Re: Pre-commit hooks are broken
#139This 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. 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. Instead, put what you want in a…
I'm the type of developer who always have a completely different way of working. I hate pre-commit hooks, and agree that pre-push + early step is CI is the right thing to do.
Re: Pre-commit hooks are broken
#140Earlier quoted context omitted.
Linear history is nice, but it is lacking the conflict resolutions. They are never committed, and neither are the ”fix rebase” instances. Having a ”fix broken merge” commit makes it explicit that there was an issue that was fixed. Rebase sometimes seems like an attempt at saving face.
That’s the whole point. You do it properly, so there IS no conflict.
No. There is a conflict during a rebase, you resolve it, and then it’s like there never was a conflict.
Even if you do it properly, the workflow is erasing history of that conflict existing and needing to be resolved. It leaves no trace of what has been worked on, when, and by whom.