91–100 of 133 posts
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…
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.
Are you asking what advantage pre-commit has over a shell script?
Mostly just functionality: running multiple hooks, running them in parallel, deciding which hooks to run based on the commit files, "decoding" the commit to a list of files, offering a bunch canned hooks, offering the ability to write and install non-shell hooks in a standard way.
Earlier quoted context omitted.
the second the hooks modify the code they've broken your sandbox I think wasi is a cool way to handle this problem. I don't think security is a reason though.
> the second the hooks modify the code they've broken your sandbox Changes to code would obviously need to be reviewed before they are committed. That's still much better than with pre-commit, where e.g. to do simple things like banning tabs you pretty much give some guy you don't know full access to your machine. Even worse - almost everyone that uses pre-commit also uses tags instead of commit hashes so the hook ca…
I agree it’s better, but not because of wasi
This is a long standing sore point in pre-commit, see https://github.com/pre-commit/pre-commit/issues/860 and also linked duplicates (some of which are not duplicates).
Pre-commit and pre-push hooks serve the purpose of keeping code isolated to a developer's machine. This is a recipe for disaster. You will run into situations where important work isn't accessible since a developer couldn't commit/push their code and the machine was lost or damaged. I've seen it happen.
I like pre-merge hooks. They're great. Pre-commit and pre-push hooks serve the purpose of keeping code isolated to a developer's machine. This is a recipe for disaster. You will run into situations where important work isn't accessible since a developer couldn't commit/push their code and the machine was lost or damaged. I've seen it happen.
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.
The benefit to many of having them as a hook is that you discover it's broken before you pushed your changes, and not when you finally get around to checking the CI on your branch and realising it failed after 30s.
There is of course no reason why you have to have it installed as a precommit hook - many people prefer to run it manually, and the pre-commit tool/prek allows for that.
Earlier quoted context omitted.
the second the hooks modify the code they've broken your sandbox I think wasi is a cool way to handle this problem. I don't think security is a reason though.
I wouldn't want hooks modifying the code. They should be only approve/reject. Ideally landlock rules would give them only ro access to repo dir
IMO if there’s a formatting issue, and the tool knows how it should look, it should fix it for you.
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 some languages there are some rather slow hooks, and using it on a big monorepo can take a while (a full run across my work's main repo takes minutes). If you update python based hooks all the time then installing and creating the virtualenvs can be slow too which prek speeds up.
Earlier quoted context omitted.
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.
The problem is that pre-commit hooks are much slower with a much higher false-positive rate than type checking. Pre-commit checks should be opt-in with CI as the gate. It's useful to be able to commit code in a failing state.