Recently I've gotten into using a rather large amount.
The most important for me is ruff, especially on personal projects with no CI.
Yelp's secrets scanner is nice. I use texthooks to block smart quotes, I block tabs, bad yaml and JSON syntax, and I use a regex to check that the string "-e " doesn't appear in requirements.txt.
I block git conflict markers and a few other trivial things.
I would use liccheck, but it has issues with detecting conflicts that don't exist in system site packages venvs.
I could see using a SPDX license header checker too.
I have a short script [1] which generates a file status.json with the package date, version and count of lines of code (with cloc). This can then be used in GitLab to generate badges of those values, as [2].
I don’t use pre-commit checks but I use linters before every PR and checks will fail and not allow a merge if they aren’t applied. I prefer flake8, black, and isort at the moment. Though, black and flake8 can conflict, but you can adjust the settings in flake8.
Might depend on your workflow. Let's say you are in a private feature branch. You do many commits, 1 per minute to create save points as you work on some mind bending logic.
You need those saves to go through no matter what, even when things are broken. You plan to squash all the feature commits when you are done so you don't care about the formatting quite as strongly for commits that will disappear soon anyway.
The most important for me is ruff, especially on personal projects with no CI.
Yelp's secrets scanner is nice. I use texthooks to block smart quotes, I block tabs, bad yaml and JSON syntax, and I use a regex to check that the string "-e " doesn't appear in requirements.txt.
I block git conflict markers and a few other trivial things.
I would use liccheck, but it has issues with detecting conflicts that don't exist in system site packages venvs.
I could see using a SPDX license header checker too.
[1] https://gitlab.com/jjg/cptutils/-/blob/master/bin/status-jso...
[2] https://gitlab.com/jjg/cptutils
I'd argue that's the point of pre-commit. Doing it for you locally before submitting the PR so you don't have to be mindful about it.
You need those saves to go through no matter what, even when things are broken. You plan to squash all the feature commits when you are done so you don't care about the formatting quite as strongly for commits that will disappear soon anyway.
You do "checks" before your commits?!?
#mustbenice ;)