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

41–50 of 133 posts

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

#41

Post by esafak »

schindlabua wrote: post #40
esafak wrote: post #38

Earlier quoted context omitted.

You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.

I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits. Slow hooks are also not a problem in projects I manage as I don't use them.

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?

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

#42

Post by schindlabua »

esafak wrote: post #41
schindlabua wrote: post #40

Earlier quoted context omitted.

I would reckon cleaning up your branch before opening a pull request is good practice. I also rebase a lot, aswell as git reset, and I use wip commits. Slow hooks are also not a problem in projects I manage as I don't use them.

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?

I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.

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

#43

Post by dpc_01234 »

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 anything special.

I have something a bit like that implemented in SelfCI (a minimalistic local-first Unix-philosophy-abiding CI) https://app.radicle.xyz/nodes/radicle.dpc.pw/rad%3Az2tDzYbAX... and it replaced my use of pre-commit hooks entirely. And users already told me that it does feel like commit hooks done right.

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

#44

Post by [deleted] »

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

I do leave PR commits separate. In my teams I don't set up pre-commit hooks altogether, unless others feel strongly otherwise. In projects where they are forced upon me I frequently --no-verify hooks if they are slow, as the linter runs on save and I run tests during development. CI failing unintentionally is usually not a problem for me.

[deleted]

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

#45

Post by esafak »

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.

Yes, you can run the CI script locally so you detect errors faster.

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

#48

Post by digdugdirk »

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?

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

#49

Post by paddy_m »

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 pointed at, if tests start passing, you probably never need to revisit the failure.

I want to know about local test failures before I push to remote with full CI.

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

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

#50

Post by aniforprez »

sangeeth96 wrote: post #34
esafak wrote: post #11

I use http://hk.jdx.dev/ , which is based on https://pkl-lang.org/ and Rust, as it integrates with http://mise.jdx.dev/ . Is prek much better?

Love mise, didn't know about hk. Will check this out but don't think $WORK (or me) needs more than lefthook at the moment, which we're quite happy with. Wonder if there are comparisons/example projects that showcases the unique value propositions.

Correct me if I'm wrong but lefthook doesn't run its hooks exclusively on the staged changes IIRC. pre-commit, and prek by extension, have a process to stash the unstaged changes using git and running the code only on the staged files. Last I used it, lefthook ran on every file regardless of git status. This annoyed me because I'd have a few stray files that were not ready to be checked in or tracked that would trigger failures in lefthook. At the time this also made some hooks run slower since it would run on every single file but I think most linters have become significantly faster now.
Post reply on HN