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

81–90 of 133 posts

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

#81

Post by sfink »

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

You can configure watchman to do it. `fsmonitor.watchman.register-snapshot-trigger = true`

I don't recommend it, though, at least not on large repositories. Too much opportunity to collide with command-line jj write operations.

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

#82

Post by thayne »

My big problem with pre-commit is that it doesn't have any way for you to have your own commit hoos that run in addition to the hooks that are part of the repo, and the author of it is hostile to any suggestion of supporting that. Heaven forbid that I want to run something on commit that other developers who work on the repo don't want to.

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

#83

Post by bradleyy »

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.

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

#84

Post by dagss »

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…

Looks very interesting, I fully agree that running CI locally is viable.

But what I didn't pick up for a quick scan of README is best pattern for integrating with git. Do you expect users to manually run (a script calling) selfci manually or is it hooked up to git or similar? When does the merge hooks come into play? Do you ask selfci to merge?

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

#85

Post by h4kunamata »

"...in Rust"

Is enough to don't even open the link! Everything right now seems to have an urgent need to be developed into Rust, like why???

Just like kubernetes, many companies followed the kubernetes hype even when it was not needed and added unnecessary complexity to a simple environment.

Now it is Rust time!!

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

#86

Post by andrewaylett »

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. And another, `jj pre-commit-branch`, that runs on a well-defined set of commits relative to @. They do use `pre-commit` internally, so I'm staying compatible with git users' use of the `pre-commit` tool.

What I can't yet do is run the checks in the background or store the check status in jj's data store. I do store the tree-ish of passing checks though, so it's really quick to re-run.

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

#87

Post by sfink »

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?

> 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 interdiffs so you can choose what view to use.)

In a better world, it would be the code author's responsibility to construct a meaningful series of commits. Unless you do everything perfectly right the first time, that means updating commits or using fixup commits. This doesn't just benefit reviewers, it's also enormously valuable when something goes wrong and you can bisect it down to one small change rather than half a dozen not-even-compiling ones.

But then, you said "atomic", which suggests you're already trying to make clean commits. How do you do that without modifying past commits once you discover another piece that belongs with an earlier step?

> You just squash on merge.

I'd rather not. Or more specifically, optimal review granularity != optimal final granularity. Some things should be reviewed separately then squashed together (eg a refactoring + the change on top). Some things should stay separate (eg making a change to one scary area and then making it to another). And optimal authoring granularity can often be yet another thing.

But I'll admit, git + github tooling kind of forces a subpar workflow.

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

#88

Post by tomjakubowski »

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.

> they … aren’t compatible with commits that leave unstaged files in your tree.

It's a little surprising that git doesn't pass pre-commit hooks any information, like a list of which files were changed in the soon-to-be-made commit. git does so for pre-push, where it writes to a hook's stdin some information about the refs and remotes involved in the push.

I wonder if many pre-commit hooks, like the kind which run formatters, would be better off as `clean` filters, which run on files when they are staged. The filter mechanism makes it easier to apply just to the files which were changed. In the git docs, they even use a formatter (`indent`) as an example.

https://git-scm.com/book/ms/v2/Customizing-Git-Git-Attribute...

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

#89

Post by fortuitous-frog »

thayne wrote: post #82

My big problem with pre-commit is that it doesn't have any way for you to have your own commit hoos that run in addition to the hooks that are part of the repo, and the author of it is hostile to any suggestion of supporting that. Heaven forbid that I want to run something on commit that other developers who work on the repo don't want to.

The author of pre-commit is known to be pretty hostile :p You should make an issue for prek though!

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

#90

Post by [deleted] »

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?

[deleted]
Post reply on HN