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

101–110 of 133 posts

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

#101

Post by chippiewill »

xyzzy_plugh wrote: post #29

Another commenter is currently down voted for something similar, but I'll share my controversial take anyways: I hate pre-commit hooks. I loathe UX flows where you get turned around. If I try to make a commit, it's because that I what I intend to do . I don't want to receive surprise errors. It's just more magic, more implicit behavior. Give me explicit tooling. If you want to use pre-commit hooks, great! You do you.…

But no one forces pre-commit hooks onto you? You can just not install the hook into git and run the tool manually instead.

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

#102

Post by [deleted] »

sfink wrote: post #87
esafak wrote: post #41

Earlier quoted context omitted.

No, I would not and don't do that. It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. You just squash on merge. > Slow hooks are also not a problem in projects I manage as I don't use them. You bypass the slow hooks you mentioned? Why even have hooks then?

> It is better to leave the PR commits separate and atomic so reviewers can digest them more easily. So reviewers have to digest all of the twists and turns I took to get to the final result? Why oh why oh why? Sure, if they've already seen some of it, then there should be an easy way for them to see the updates. (Either via separate commits or if you're fortunate enough to have a good review system, integrated inter…

[deleted]

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

#103

Post by epage »

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.

For me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.

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

#104

Post by smoyer »

andrewaylett wrote: post #86
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…

Just because the hooks have the label "pre-commit" doesn't mean you have to run them before committing :). I, too, want checks per change in jj -- but (in part because I need to work with people who are still using git) I need to still be able to use the same checks even if I'm not running them at the same point in the commit cycle. So I have an alias, `jj pre-commit`, that I run when I want to validate my commits. A…

My agents gave to run pre-commit before calling a coding tag done. In this case, it's just a robust set of checks.

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

#106

Post by [deleted] »

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

[deleted]

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

#107

Post by chrisweekly »

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

I prefer to configure my IDE to apply precisely the same linting and formatting rules as used for commits and in CI. Save a file, see the results, nothing changes between save, commit, stage, push, PR, merge.

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

#108

Post by stavros »

smoyer wrote: post #104
andrewaylett wrote: post #86

Earlier quoted context omitted.

Just because the hooks have the label "pre-commit" doesn't mean you have to run them before committing :). I, too, want checks per change in jj -- but (in part because I need to work with people who are still using git) I need to still be able to use the same checks even if I'm not running them at the same point in the commit cycle. So I have an alias, `jj pre-commit`, that I run when I want to validate my commits. A…

My agents gave to run pre-commit before calling a coding tag done. In this case, it's just a robust set of checks.

Same, and I also run them on CI. It's just handy as a check runner.

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

#109

Post by teaearlgraycold »

bradleyy wrote: post #83
teaearlgraycold wrote: post #59

It doesn’t seem like this solves the main issues with pre-commit hooks. They are broken by design. Just to name 2, they run during rebase and aren’t compatible with commits that leave unstaged files in your tree.

I leave unstaged files all the time, not sure what you mean.

Without extra shenanigans if you have an unstaged file that fails your test suite then pre-commit will reject your commit even if the staged files are error free.

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

#110

Post by laughingcurve »

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 had been eagerly moving over to using JJ when I discovered that 'hook' behavior was not present. Pre-push hooks for formatting and linting were very helpful for me because I needed to enforce these standards on others who were more junior. It would be great for JJ to incorporate it in some way if possible. I understand the structural differences and why that makes it hard but something about that pre-* hook just hits right
Post reply on HN