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

61–70 of 133 posts

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

#61

Post by jiehong »

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…

Yep, I think a watcher is better suited [0] to trigger on file changes.

I personally can't stand my git commit command to be slow or to fail.

[0]: such as https://github.com/watchexec/watchexec

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

#62

Post by dijksterhuis »

schindlabua wrote: post #22
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?

This might be a me problem but I extensively manipulate the git history all the time which makes me loathe git hooks. A commit should take milliseconds, not a minute.

it’s not just you.

i regularly edit history of PRs for a variety of reasons and avoid pre-commit when possible.

put it all in CI thank you please — gimme a big red X on my pipeline publicly telling me i’ve forgotten to do something considered important.

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

#63

Post by lukasgraf »

thoughtpalette wrote: post #9
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?

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 pipeline fail fast if they don't pass. Instant Slack notification on fail.

But the fastest feedback is obviously in the editor, where such checks like linting / auto-formatting belong, IMHO. There I can see what gets changed, and react to it.

Pre-commit hooks sit in such a weird place between where I author my code (editor) and the last line of defense (CI).

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

#64

Post by jiehong »

jiehong wrote: post #61
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…

Yep, I think a watcher is better suited [0] to trigger on file changes. I personally can't stand my git commit command to be slow or to fail. [0]: such as https://github.com/watchexec/watchexec

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!

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

#65

Post by nsm »

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?

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

#66

Post by wrs »

jiehong wrote: post #64
jiehong wrote: post #61

Earlier quoted context omitted.

Yep, I think a watcher is better suited [0] to trigger on file changes. I personally can't stand my git commit command to be slow or to fail. [0]: such as https://github.com/watchexec/watchexec

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

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

#67

Post by paulsmith »

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 something that runs a local CI (like a watcher/other automated process).

I haven't yet submitted it to upstream for design discussion, but I pushed up my branch[1]. You can also declare a revset that the target revision must match, for extra belts and suspenders (eg., '~conflicts()')

[1] https://github.com/paulsmith/jj/tree/protected-bookmarks

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

#68

Post by globular-toast »

fishgoesblub wrote: post #5

Am I alone in that I never have had an issue with performance with pre-commit? granted I don't work on projects the size of the Linux kernel, but I haven't had any complaints.

Never had a problem. It adds negligible time to each commit and I have several hooks in use. Running tests takes several orders of magnitude more time.

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

#69

Post by Marsymars »

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?

> Can people give examples of how they use pre-commit hooks that _cannot_ be replaced by a combination of the following?

I can't, because the point of our pre-commit use isn't to run logic in hooks that can't be run otherwise.

e.g. We use pre-commit to enforce that our language's whitespace formatting has been applied. This has the same configuration in the IDE, but sometimes devs ignore IDE warnings or just open files in a text editor for a quick edit and don't see IDE warnings or w/e.

"Replaced by CI" isn't really meaningful in our context - pre-commit is just a tool that runs as part of CI - some things get done as pre-commit hooks because they're fast and it's a convenient place to put them. Devs are encouraged to also run pre-commit locally, but there's no enforcement of this.

> 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?

We have performance metrics for pre-commit hooks and pre-push hooks. I forget the exact numbers, but we want stuff to "feel" fast, so e.g. if you're rebasing something locally with a few dozen commits it should only take seconds. Pre-push hooks have a bit more latitude.

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

#70

Post by wocram »

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…

Being visible is useful, this is probably better suited for an ide than a hook or a daemon.
Post reply on HN