-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add --commit flag to more easily lint a single commit #141
Comments
Hi! Thanks for opening the issue. I agree this doesn't work, but this is correct behavior. Note the following line right below where you copied that example from:
In other words, gitlint just passes the refspec onto git itself. Turns out, your example isn't valid refspec. The good news is it's easy to fix by just changing your Taking SHA # This doesn't work, because it's invalid refspec (as per git's definition)
$ git rev-list "765a4427f80ccdda61bc78e2680bda14787b2a4e^..765a4427f80ccdda61bc78e2680bda14787b2a4e"
fatal: ambiguous argument '765a4427f80ccdda61bc78e2680bda14787b2a4e^..765a4427f80ccdda61bc78e2680bda14787b2a4e': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
# This *does* work!
$ git rev-list 765a4427f80ccdda61bc78e2680bda14787b2a4e
765a4427f80ccdda61bc78e2680bda14787b2a4e
# In other words, to lint the first commit you can just pass the SHA on its own
$ gitlint --commits 765a4427f80ccdda61bc78e2680bda14787b2a4e
3: B6 Body message is missing Refspec is tricky and not always intuitive. I can see that the example from gitlint's docs doesn't consider this special first-commit case and might lead to some frustration as you experienced. I'll keep this issue open to update the docs accordingly! |
|
You're right. Unfortunately, it comes down to how refspec works. I originally wanted to support using a single commit SHA to specify a single commit to lint, but that goes directly against the refspec format where a single SHA usually defines a range of commits. I spend a lot of time pondering about this and ultimately decided it's best to not change semantics and pass the refspec directly to git. I'm not against revisiting that, but I do have a pretty strong opinion against gitlint having an internal refspec parser. That is both tricky to get right (example: #23, #35) and arguably poor practice (we should avoid re-implement core git features). So it's a trade-off - I don't think there's a perfect solution. Hope that makes sense :-) Again, I'll clarify this in the docs! |
What do you think about a new option that would accept a single commit, and nothing else? |
Yes, possible 👍 I'll leave this here 😎 (Most of the work is in writing tests/docs, not the business logic itself). |
Support for new convenience CLI flag `--commit` which allows for each linting of a single commit. Implements #141
Support for new convenience CLI flag `--commit` which allows for each linting of a single commit. Implements #141
- Python 3.10 support - New Rule: ignore-by-author-name allows users to skip linting commit messages made by specific authors - --commit <SHA> flag to more easily lint a single commit message (#141) - --fail-without-commits flag will force gitlint to fail (exit code 253) when the target commit range is empty (typically when using --commits) (#193) - Bugfixes: - contrib-title-conventional-commits (CT1) now properly enforces the commit type (#185) - contrib-title-conventional-commits (CT1) now supports the BREAKING CHANGE symbol "!" (#186) - Under-the-hood: dependencies updated, test and github action improvements. Full Release details in CHANGELOG.md.
Closing this issue - this was implemented as part of 0.16.0 |
The documentation suggests to use the following syntax for linting a single commit:
https://jorisroovers.com/gitlint/#linting-a-range-of-commits
However, this syntax doesn't work for the initial commit, because it has no parent.
The text was updated successfully, but these errors were encountered: