Comment by fishgoesblub
9 hours ago
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.
9 hours ago
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 me the issue isn't performance but bad hook updating logic. They expect hooks to be managed in isolated repos with exclusive use of tags. I have my gh action and hook in the repo of my program and it has been a source of pain to users but I'd rather drop pre-commit support than have to deal with update across repos. prek fixed this.
It depends on the hooks you're using and how many of them.
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.
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?
Never had a problem. It adds negligible time to each commit and I have several hooks in use. Running tests takes several orders of magnitude more time.