-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Prevent Commas in text fields from breaking git log printing #37
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The comma seperator for git log pretty print caused errors when the text fields have commas in them. To remedy this, the delimiter was changed to a nul character.
asottile
approved these changes
Sep 20, 2017
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is usually what's recommend in the git documentation (see also -z
)
This is great, I apologize for the delay. Merging this. I'm planning to release 0.9.0 soon so this will be included in that. |
jorisroovers
pushed a commit
that referenced
this pull request
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 pull request
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.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have had a few users with names formatted as "Surname, GivenName" that would cause git lint to error. In order to remedy this, I modified the delimiter to be a nul byte (which should never occur) for the git log --pretty command.