zlacker

>>DrBenC+(OP)
Interesting. I've been working on a pre-commit replacement too, written in Rust but using WASI for all plugins (no exceptions!). I haven't got very far but I think this will have huge advantages over pre-commit, mostly in reliability.

Me and my colleagues have had numerous issues setting up pre-commit because it inherits Python's atrocious infrastructure.

I'm curious how this is going to deal with actually running plugins? Will it take the same approach as pre-commit and add dedicated not-very-good support for a load of different languages?

>>timhh+tm
Pre-commit has like the worst DX to me, so I'm really looking forward to a replacement.

My biggest gripes are:

1. Pre-commit hooks are designed to modify files in-place, which turns `git commit` into something that can alter your work tree. IMO those tools should never ever modify files (unless explicitly asked by the user) and only output a diff and exit code that signifies if the check failed.

2. It manages the tools with its own environment but never exposes it. I always have to dig around its cache directory to find out which executable it is running if I have to reproduce the problem after something goes wrong.