3 ms·

Ask HN: What are the Git pre-commit checks you prefer the most?

6 points by vinnyglennon 3y ago

jjgreen 3y ago
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]. [1] https://gitlab.com/jjg/cptutils/-/blob/master/bin/status-json https://gitlab.com/jjg/cptutils/-/blob/master/bin/status-jso... [2] https://gitlab.com/jjg/cptutils https://gitlab.com/jjg/cptutils
warrenm 3y ago
Wait! You do "checks" before your commits?!? #mustbenice ;)
interbased 3y ago
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.
- Gooblebrai 3y ago
  So you need to remember doing the linting and formatting or the PR will fail? 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.
  - foobarbaz33 3y ago
    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.
dev_0 3y ago
[dead]
eternityforest 3y ago
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.

6 points by vinnyglennon 3y ago

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]. [1] https://gitlab.com/jjg/cptutils/-/blob/master/bin/status-json https://gitlab.com/jjg/cptutils/-/blob/master/bin/status-jso... [2] https://gitlab.com/jjg/cptutils https://gitlab.com/jjg/cptutils

warrenm 3y ago

Wait! You do "checks" before your commits?!? #mustbenice ;)

interbased 3y ago

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.

Gooblebrai 3y ago
So you need to remember doing the linting and formatting or the PR will fail? 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.
- foobarbaz33 3y ago
  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.

dev_0 3y ago

[dead]

eternityforest 3y ago

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.