Filling the CI/CD pipeline with tiny commits to fix linting when it should be done before commit or push is why pre-commit exists. It's not BS, clogging the job queue shits in everyone else.
Of course I don't know GPs specific context so they may have other details, but generally it's
Except this problem rarely comes up. Everyone has their favorite way to set up their editors to lint and format automatically using the project's config.
Over my career, I see that every company has some version of:
1. New guy joins a team, wants to push code ASAP
2. He sets up his favorite editor and punt configuring linters and formatters
3. Code pushed, CI fails at linting
4. Some well-meaning coworker or new guy suggests some variations of husky/pre-commit/fancy git hook scripts
5. Team agrees and put that into the repo
6. 6 months to 1 year later the entire team realizes its benefit does not out-weight the cost, and unanimously agree to rip it out unceremoniously.
Well I have different experiences where no one would ever go back to living without pre-commit, black, autoflake, etc. It moves the fixes to before they get to CI. There's literally no downside.
Maybe you have experience with some weird tool? Or running black and autoflake messed around with emacs and it needs to reload all the buffers?
I initially had some problems, then I've written an emacs package[1] to fix all of them. And it's due to the course of writing this package made me realize just how bad pre-commit is from its UX, design to its entire premise.
Ok then I think the issue is not so much pre-commit but that python tooling in general should not be written in python. It's a minority opinion but the fact that there is a tooling python and an application python can mess with things as you're experiencing.
Of course I don't know GPs specific context so they may have other details, but generally it's