if an LLM says "I can't open a PR automatically until you solicit a review from a maintainer", i think that's good actually. likewise for proactively following the rest of the rules.
It's not the submitter who solicits, but the reviewer. They can't give code, AND THEN get approval, they need to be asked specifically for an llm created PR.
the pre-commit framework does not abstract away “hooks shouldn’t be run during a rebase”, nor “hooks should be fast and reliable”, nor “hooks should never change the index”.
Not sure how you got to that conclusion, as the pre-commit framework does indeed abstract them away. Maybe you're confusing it with something else?
> hooks shouldn’t be run during a rebase
The pre-commit framework doesn't run hooks during a rebase.
> hooks should be fast and reliable
The pre-commit framework does its best to make hooks faster (by running them in parallel if possible) and more reliable (by allowing the hook author to define an independent environment the hook runs in), however it's of course still important that the hooks themselves are properly implemented. Ultimately that's something the hook author has to solve, not the framework which runs them.
> hooks should never change the index
As I read it the author says hooks shouldn't change the working tree, but the index insteead and that's what the pre-commit framework does if hooks modify files.
Personally I prefer configuring hooks so they just print a diff of what they would've changed and abort the commit, instead of letting them modify files during a commit.
> Ultimately that's something the hook author has to solve, not the framework which runs them.
correct. i'm saying that hook authors almost never do this right, and i'd rather they didn't even try and moved their checks to a pre-push hook instead.
It fills me with joy to know that those are irreconcilable. It lifts the burden of having to reconcile these things and I know that my self expression can be directed elsewhere.
Whatever beauty exists in engineering comes from the purity of it. A fighter plane or a microchip looks beautiful, not because it was designed to be so, but because of the purity of the functionality, the harshness of the requirements.
If you turn a fighter plane into an art project, then it will be inherently ridiculous. It will make a mockery of its own purpose, looking at it will be like looking at a cripple.
> it's often that the amount of time i've spent thinking about something (a lot) is totally disproportionate to the time i spend typing my thoughts up (a little)
oh, this is a really good way of putting it! that’s exactly what happened :)
you could build an emacs frontend for this model! the thing i am trying to describe is “getting out of the box”. imagine a terminal session that is shared between emacs, iTerm, and a mobile phone ssh’d in over the network, that’s my vision.
> Great, now you just need to build and maintain shims for every tool in existence, force your users to use your own custom tools that support these features, and ensure that everything interoperates smoothly.
reply