--commits doesn't correctly handle refspec #23
Labels
bug
User-facing bugs
Comments
jorisroovers
pushed a commit
that referenced
this issue
Mar 16, 2017
The 0.8.1 release brings minor tweaks and some experimental features. Special thanks to tommyip for his contributions. - Experimental: Linting a range of commits. Known Caveats: #23, #24. Thanks to tommyip for implementing this! - Experimental: Python 3.6 support - Improved Windows error messaging: gitlint will now show a more descriptive error message when ran on windows. See #20 for details on the lack of Windows support. Full Release details in CHANGELOG.md.
jorisroovers
pushed a commit
that referenced
this issue
Jun 7, 2017
This fixes #23. Still needs tests.
jorisroovers
pushed a commit
that referenced
this issue
Jul 3, 2017
This fixes #23. Still needs more tests.
jorisroovers
pushed a commit
that referenced
this issue
Jul 14, 2017
Gitlint did not correctly handle all refspec formats that were supported by `git rev-list`. It does now :) This fixes #23.
jorisroovers
added a commit
that referenced
this issue
Jul 14, 2017
Gitlint did not correctly handle all refspec formats that were supported by `git rev-list`. It does now :) This fixes #23.
jorisroovers
pushed a commit
that referenced
this issue
Dec 3, 2017
The 0.9.0 release adds a new default author-valid-email rule, important bugfixes and special case handling. Special thanks to joshholl, ron8mcr, omarkohl, domo141, nud and AlexMooney for their contributions. - New Rule: author-valid-email enforces a valid author email address. Details can be found in the Rules section of the documentation. - Breaking change**: The --commits commandline flag now strictly follows the refspec format as interpreted by the git rev-list <refspec> command. This means that linting a single commit using gitlint --commits <SHA> won't work anymore. Instead, for single commits, users now need to specificy gitlint --commits <SHA>^...<SHA>. On the upside, this change also means that gitlint will now understand all refspec formatters, including gitlint --commits HEAD to lint all commits in the repository. This fixes #23. - Breaking change**: Gitlint now always falls back on trying to read a git message from a local git repository, only reading a commit message from STDIN if one is passed. Before, gitlint only read from the local git repository when a TTY was present. This is likely the expected and desired behavior for anyone running gitlint in a CI environment. This fixes #40 and #42. - Behavior Change**: Gitlint will now by default ignore squash and fixup commits (fix for #33). - Support for custom comment characters (#34). - Support for 'git commit --cleanup=scissors' (#34). - Bugfix: #37: Prevent Commas in text fields from breaking git log printing - Debug output improvements Full Release details in CHANGELOG.md.
RykHawthorn
pushed a commit
to RykHawthorn/gitlint
that referenced
this issue
Jan 12, 2018
The 0.9.0 release adds a new default author-valid-email rule, important bugfixes and special case handling. Special thanks to joshholl, ron8mcr, omarkohl, domo141, nud and AlexMooney for their contributions. - New Rule: author-valid-email enforces a valid author email address. Details can be found in the Rules section of the documentation. - Breaking change**: The --commits commandline flag now strictly follows the refspec format as interpreted by the git rev-list <refspec> command. This means that linting a single commit using gitlint --commits <SHA> won't work anymore. Instead, for single commits, users now need to specificy gitlint --commits <SHA>^...<SHA>. On the upside, this change also means that gitlint will now understand all refspec formatters, including gitlint --commits HEAD to lint all commits in the repository. This fixes jorisroovers#23. - Breaking change**: Gitlint now always falls back on trying to read a git message from a local git repository, only reading a commit message from STDIN if one is passed. Before, gitlint only read from the local git repository when a TTY was present. This is likely the expected and desired behavior for anyone running gitlint in a CI environment. This fixes jorisroovers#40 and jorisroovers#42. - Behavior Change**: Gitlint will now by default ignore squash and fixup commits (fix for jorisroovers#33). - Support for custom comment characters (jorisroovers#34). - Support for 'git commit --cleanup=scissors' (jorisroovers#34). - Bugfix: jorisroovers#37: Prevent Commas in text fields from breaking git log printing - Debug output improvements Full Release details in CHANGELOG.md.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example,
gitlint --commits HEAD~2isn't correctly handled: it only lints the first commit in that range instead of all. This is because we are checking for the presence of dots in the refspec and if not present, add an additional--max-countargument when invoking git, see here: https://github.com/jorisroovers/gitlint/blob/master/gitlint/git.py#L127-L131I think instead we will most likely have to add an additional check for the number of commits in the repository to correctly handle the refspec format.
CC: @tommyip
The text was updated successfully, but these errors were encountered: