I don't understand. The whole point of pre-commit is it's a gateway to the operating system and also creating a ecosystem of pre integration continuous integration scripts. Scripts that are not rust.
Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
31–40 of 133 posts
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#32I always just disable pre-commit
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#33Earlier 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.
The point is enforcement. If there's a newcomer to developing your repo, you can ask them to install the hooks and from thereon everything they commit will be compatible with the processes in your CI. You don't need to manually run the scripts they'll run automatically as part of the commit or push or whatever process
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#34I 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.
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#35I always just disable pre-commit
[deleted]
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#36I 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.
formatting should definitely be in pre-commit though, otherwise you'll destroy diffs.
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#37Another 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.…
Client-side pre-commit hooks are there to help you in the same way that type checking (or a powerful compiler) is there to help you avoid bugs. In particular with git, you can skip the hooks when committing.
Now, if the server enforces checks on push, that's a project policy that should be respected.
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#38I 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.
You do seem to be doing it wrong. Extensive manipulation of the record and slow hooks are both undesirable.
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#39Am 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.
I've used pre-commit very sparingly but it has happened and I also have no idea why this project need to exist? Why would pre-commit ever lead to performance problems? I get that the processes that are hooked in can be long running but the pre-commit itself? Why would it take any time at all?
Re: Prek: A better, faster, drop-in pre-commit replacement, engineered in Rust
#40Earlier quoted context omitted.
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.
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.