Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

github.com

Post reply on HN
Print view View original

71–80 of 133 posts

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#71

Post by Marsymars »

lukasgraf wrote: post #63
thoughtpalette wrote: post #9

Earlier quoted context omitted.

You can obviously bypass them, but having precommit hooks to run scripts locally, to make sure certain checks pass, can save them from failing in your pipeline, which can save time and money. From an org standpoint you can have them (mandate?) as part of the developer experience. (Our team doesn't use them, but I can see the potential value)

I never understood this argument. The checks in those pre-commit hooks would need to be very fast - otherwise they'd be too slow to run on every commit. Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pip…

> Then why would it save time and money if they only get run at the pipeline stage? That would only save substantial time if the pipepline is architected in a suboptimal way: Those checks should get run immediately on push, and first in the pipeline so the make the pipeline fail fast if they don't pass. Instant Slack notification on fail.

That's still multiple minutes compared to an error thrown on push - i.e. long enough for the dev in question to create a PR, start another task, and then leave the PR open with CI failures for days afterwards.

> But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO.

There are substantial chunk of fast checks that can't be configured in or that require a disproportionate time investment. (e.g. you could write and maintain a Visual Studio extension vs just adding a line to grep for pre-commit)

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#73

Post by Marsymars »

JoshTriplett wrote: post #19
candiddevmike wrote: post #4

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?

I think there's value in git hooks, but pre-commit is the wrong hook. This belongs in a hook that runs on attempted push, not on commit.

"pre-commit the tool" supports the pre-push hook (as well as the various other hooks).

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#74

Post by Marsymars »

candiddevmike wrote: post #18
BeeOnRope wrote: post #17

Earlier quoted context omitted.

They integrate well with CI. You run the same hooks in CI as locally so it's DRY and pushes people to use the hooks locally to get the early feedback instead of failing in CI. Hooks without CI are less useful since they will be constantly broken.

Why wouldn't I just call the same shell script in CI and locally though? What's the benefit here? All I'm seeing is circular logic.

pre-commit provides a convenient way to organize running a collection of shell scripts.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#75

Post by stavros »

wrs wrote: post #66
jiehong wrote: post #64

Earlier quoted context omitted.

To myself: sometimes I think the background process should be committing for me automatically each time a new working set exists, and I should only rebase and squash before pushing. That’s reversing the flow of control, but might be workable!

jj already pretty much does that with the oplog. A consistent way of making new snapshots in the background would be nice though. (Currently you have to run a jj command — any jj command — to capture the working directory.)

I don't think you have to, you can run the integrated watcher, no?

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#76

Post by dpc_01234 »

digdugdirk wrote: post #48
dpc_01234 wrote: post #43

BTW. Pre-commit hooks are the wrong way to go about this stuff. I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do…

That looks really cool! I've been looking for a more thought-out approach to hooks on JJ, I'll dig into this. Do you have any other higher level architecture/overview documentation other than what is in that repo? It has a sense of "you should already know what this does" from the documentation as is. Also, how do you like Radicle?

> Do you have any other higher level architecture/overview documentation other than what is in that repo?

SelfCI is _very_ minimal by design. There isn't really all that much to document other than what is described in the README.

> Also, how do you like Radicle?

I enjoy that it's p2p, and it works for me in this respect. Personally I disagree with it attempt to duplicate other features of GitHub-like forge, instead of the original collaborate model of Linux kernel that git was built for. I think it should try to replicate something more like SourceHut, mailinglist thread, communication that includes patches, etc. But I did not really _collaborated_ much using Radicle yet, I just push and pull stuff from it and it works for that just fine.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#77

Post by dpc_01234 »

paddy_m wrote: post #49
dpc_01234 wrote: post #43

BTW. Pre-commit hooks are the wrong way to go about this stuff. I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do…

That's a great idea, and I was just thinking about how it would pair with self hosted CI of some type. Basically what I would want is write a commit (because I want to commit early and often) then run the lint (and tests) in a sandboxed environment. if they pass, great. if they fail and HERAD has moved ahead of the failing commit, create a "FIXME" branch off the failure. back on main or whatever branch head was point…

> automatic branching and workflow stuff is optional. the core idea is great.

I'm not sure if I fully understood. But SelfCI's Merge-Queue (mq) daemon has a built-in hook system, so it's possible to do custom stuff at certain points. So probably you should be able to implement it already, or it might require couple of minor tweaks (should be easy to do on SelfCI side after some discussion).

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#78

Post by dpc_01234 »

paulsmith wrote: post #67
dpc_01234 wrote: post #43

BTW. Pre-commit hooks are the wrong way to go about this stuff. I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do…

I like this approach. Something related I've been tinkering with are "protected bookmarks" - you declare what bookmarks (main, etc) are protected in your config.toml and the normal `jj bookmark` commands that change the bookmark pointer will fail, unless you pass a flag. So in your local "CI" script you can do `jj bookmark set main -r@ --allow-protected` iff the tests/lints pass. Pairs well with workspaces and someth…

Cool! That would pair well with SelfCI's MQ daemon, preventing accidentally forgetting about merging in stuff without running the local CI.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#79

Post by acdha »

nsm wrote: post #65

Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following? * CI (I understand pre-commit shifts errors left) * in editor/IDE live error callouts for stuff like type checking, and auto-formatting for things like "linters". Do you run tests? How do you know _which_ tests to run, and not just run every test CI would run, which could be slow?

It’s a question of feedback time and consistency: e.g. if you run Prettier/Ruff in CI, someone has to wait minutes rather than milliseconds and you either have to fix build failures or grant your CI system commit privileges and deal with merge conflicts. This also means more total CI runner usage while someone’s laptop probably has 10 idle cores.

If it’s on a pull/merge request, you’re wasting reviewer time.

If the hook is blocking secrets, you can’t un-push it with 100% certainty so you have to revoke credentials.

For texts, I tend to have the equivalent of “pytest tests/unit/“ since those are fast and a good sanity check, especially for things like refactoring.

I also run our pre-commit checks in CI for consistency so we’re never relying on someone’s local environment (web editors exist) and to keep everyone honest about their environment.

Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust

#80

Post by agumonkey »

dpc_01234 wrote: post #43

BTW. Pre-commit hooks are the wrong way to go about this stuff. I'm advocating for JJ to build a proper daemon that runs "checks" per change in the background. So you don't run pre-commit checks when committing. They just happen in the background, and when by the time you get to sharing your changes, you get all the things verified for you for each change/commit, effortlessly without you wasting time or needing to do…

I want multilayered reactive DAG ala Maya for source code
Post reply on HN