Looks like this is just a clone of pre-commit, with the same general design.
> pre-commit is a framework to run hooks written in many languages, and it manages the language toolchain and dependencies for running the hooks
The “and” here are the main annoyances with pre-commit. It does too many things, which would each be best served by a separate tool.
As a developer working on a project, I already have mechanisms to set up a development environment. Having pre-commit install another copy of the dev environment is redundant, and typically necessitates duplicating dependency declarations too.
I’d much rather see a tool that focuses on running commit hooks, while leaving dependency management to another tool. Most projects already have something in place anyway, since dependencies are necessary for development beyond the scope of pre-commit hooks.
The really useful part of pre-commit is that it: (1) only runs hooks based on file that changed and (2) stashes all unstaged changes and untracked files.
The latter is possibly just a Git feature that should come into existence (it's annoying to have to make sure your hook is robust against this). But I think "being a package manager" is what they think the main point is.
Agreed. For a Rust project, running Clippy and rustfmt is slow, but I’d be surprised to learn that pre-commit itself was a non-negligible part of that.
I wish there's a better comparison to other native solutions like lefthook. I assume the builtin hooks is a core differentiator but I'm not sure if this would be useful outside the Python community.
Imho pre-commit is an antipattern. It tends to break (or rather the janky things it typically runs break) but more importantly whatever needs to be run to gate commits has to be run server-side anyway (people disable precommit, it sometimes produces false negatives, so can't be relied upon). So once you're running the checks server side now you have a second problem which is that the two checks don't always produce the same result. Better to enforce checks in CI, but also provide a way for the dev to run the same check themselves, manually.
Well, I have one well-documented exception to this rule: Secret detection. You really don't want to push secrets to your repository, especially if it's hosted as public on GitHub. Those damned attackers can find the secrets in minutes after you've pushed them so you really don't have the time to catch and rotate this (unless you're able to properly attribute and rotate them from the CI... in which case, I'd love to see it).
> pre-commit is a framework to run hooks written in many languages, and it manages the language toolchain and dependencies for running the hooks
The “and” here are the main annoyances with pre-commit. It does too many things, which would each be best served by a separate tool.
As a developer working on a project, I already have mechanisms to set up a development environment. Having pre-commit install another copy of the dev environment is redundant, and typically necessitates duplicating dependency declarations too.
I’d much rather see a tool that focuses on running commit hooks, while leaving dependency management to another tool. Most projects already have something in place anyway, since dependencies are necessary for development beyond the scope of pre-commit hooks.
The really useful part of pre-commit is that it: (1) only runs hooks based on file that changed and (2) stashes all unstaged changes and untracked files.
For me, I would say the most intriguing feature is no Python dependencies.