Hi!
tl;dr https://www.mediawiki.org/wiki/commit-message-validator
Commit messages are pretty important - they make it easy to figure out what a change does without reading the entire diff. And because of that, we have some guidelines[1] on how to format your commit message in the standard way.
But sometimes people aren't familiar with the guidelines, or more likely we make a typo somewhere. Here's where the commit-message-validator[2] comes in handy!
$ git commit <type in commit message and save> commit-message-validator v0.5.1 The following errors were found: Line 1: First line should be <=80 characters Line 3: Bug: value must be a single phabricator task ID Please review https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines and update your commit message accordingly
Or if you did a good job: commit-message-validator v0.5.1 Commit message is formatted properly! Keep up the good work!
Installing it as a git hook is the recommended usage, and instructions on the wiki page[2] explain how to do so, even for people who aren't familiar with Python.
The tool was written by Bryan Davis, Fabian Neundorf, and myself. Bugs/feature requests can be filed in the Phabricator project.
[1] https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines [2] https://www.mediawiki.org/wiki/Commit-message-validator
-- Legoktm
This is great, thanks Kunal, Bryan and Fabian :)
On Tue, Nov 7, 2017 at 11:28 AM, Kunal Mehta legoktm@member.fsf.org wrote:
Hi!
tl;dr https://www.mediawiki.org/wiki/commit-message-validator
Commit messages are pretty important - they make it easy to figure out what a change does without reading the entire diff. And because of that, we have some guidelines[1] on how to format your commit message in the standard way.
But sometimes people aren't familiar with the guidelines, or more likely we make a typo somewhere. Here's where the commit-message-validator[2] comes in handy!
$ git commit
<type in commit message and save> commit-message-validator v0.5.1 The following errors were found: Line 1: First line should be <=80 characters Line 3: Bug: value must be a single phabricator task ID Please review <https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines> and update your commit message accordingly
Or if you did a good job: commit-message-validator v0.5.1 Commit message is formatted properly! Keep up the good work!
Installing it as a git hook is the recommended usage, and instructions on the wiki page[2] explain how to do so, even for people who aren't familiar with Python.
The tool was written by Bryan Davis, Fabian Neundorf, and myself. Bugs/feature requests can be filed in the Phabricator project.
[1] https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines [2] https://www.mediawiki.org/wiki/Commit-message-validator
-- Legoktm
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2017-11-07 7:58 GMT+02:00 Kunal Mehta legoktm@member.fsf.org:
But sometimes people aren't familiar with the guidelines, or more likely we make a typo somewhere. Here's where the commit-message-validator[2] comes in handy!
Does the tool check for typos? Typos in commit messages get merged all the time, including my own. I would like to avoid that :)
-Niklas
On Mon, Nov 6, 2017 at 11:59 PM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
2017-11-07 7:58 GMT+02:00 Kunal Mehta legoktm@member.fsf.org:
But sometimes people aren't familiar with the guidelines, or more likely we make a typo somewhere. Here's where the commit-message-validator[2] comes in handy!
Does the tool check for typos? Typos in commit messages get merged all the time, including my own. I would like to avoid that :)
We could probably add checks for some common ones if someone compiled a list.
Running a full spell check would be difficult because of the number of false positives there would be based on a "normal" dictionary. Commit messages often contain technical jargon (maybe something to try and avoid) and snippets of code (e.g. class names like TemplatesOnThisPageFormatter) that would not be in any traditional dictionary that we could count on being on the local host.
Bryan
On Tue, Nov 07, 2017 at 11:19:57AM -0700, Bryan Davis wrote:
We could probably add checks for some common ones if someone compiled a list.
Running a full spell check would be difficult because of the number of false positives there would be based on a "normal" dictionary. Commit messages often contain technical jargon (maybe something to try and avoid) and snippets of code (e.g. class names like TemplatesOnThisPageFormatter) that would not be in any traditional dictionary that we could count on being on the local host.
Debian's lintian (lint tool for packages) has a check for common typos/misspellings in its informational mode. The package ships with /usr/bin/spellintian which is a simple spellchecker that can run independently.
The benefit of using spellintian over e.g. aspell is that it addresses the issues you already identified: a) it just identifies typos, not complaining on unknown words it doesn't know, b) it's been created from observing typos in source code and package descriptions in the wild, so it's tailored to technical jargon and their misspellings. It could be a good fit to git commit messages.
That doesn't mean it's free of false positives though, so I wouldn't recommend to use it in a voting check in a CI pipeline.
Faidon
On Tue, Nov 7, 2017 at 10:45 AM Faidon Liambotis faidon@wikimedia.org wrote:
On Tue, Nov 07, 2017 at 11:19:57AM -0700, Bryan Davis wrote:
We could probably add checks for some common ones if someone compiled a
list.
Running a full spell check would be difficult because of the number of false positives there would be based on a "normal" dictionary. Commit messages often contain technical jargon (maybe something to try and avoid) and snippets of code (e.g. class names like TemplatesOnThisPageFormatter) that would not be in any traditional dictionary that we could count on being on the local host.
Debian's lintian (lint tool for packages) has a check for common typos/misspellings in its informational mode. The package ships with /usr/bin/spellintian which is a simple spellchecker that can run independently.
The benefit of using spellintian over e.g. aspell is that it addresses the issues you already identified: a) it just identifies typos, not complaining on unknown words it doesn't know, b) it's been created from observing typos in source code and package descriptions in the wild, so it's tailored to technical jargon and their misspellings. It could be a good fit to git commit messages.
That doesn't mean it's free of false positives though, so I wouldn't recommend to use it in a voting check in a CI pipeline.
Plus, you know, intentional misspellings:
"Fix misspelling of wikinedia -> wikimedia"
-Chad
I would be more than willing to help, keyword help, compile a common typo list. Just let me know and I could start up a spreadsheet or something.
Sent from my iPhone
On Nov 7, 2017, at 1:26 PM, Chad innocentkiller@gmail.com wrote:
On Tue, Nov 7, 2017 at 10:45 AM Faidon Liambotis faidon@wikimedia.org wrote:
On Tue, Nov 07, 2017 at 11:19:57AM -0700, Bryan Davis wrote: We could probably add checks for some common ones if someone compiled a
list.
Running a full spell check would be difficult because of the number of false positives there would be based on a "normal" dictionary. Commit messages often contain technical jargon (maybe something to try and avoid) and snippets of code (e.g. class names like TemplatesOnThisPageFormatter) that would not be in any traditional dictionary that we could count on being on the local host.
Debian's lintian (lint tool for packages) has a check for common typos/misspellings in its informational mode. The package ships with /usr/bin/spellintian which is a simple spellchecker that can run independently.
The benefit of using spellintian over e.g. aspell is that it addresses the issues you already identified: a) it just identifies typos, not complaining on unknown words it doesn't know, b) it's been created from observing typos in source code and package descriptions in the wild, so it's tailored to technical jargon and their misspellings. It could be a good fit to git commit messages.
That doesn't mean it's free of false positives though, so I wouldn't recommend to use it in a voting check in a CI pipeline.
Plus, you know, intentional misspellings:
"Fix misspelling of wikinedia -> wikimedia"
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Not exactly the same, but worth mentioning, there's an npm package for grunt that was developed originally in the VE team and is used in some of our repos that's being used in some of our repos called grunt-tyops https://www.npmjs.com/package/grunt-tyops
I don't think it can work on the commit message, but it might be a good place to start or get inspiration from :)
(Also, it's a great package to use in JS-heavy extensions in general)
On Tue, Nov 7, 2017 at 12:28 PM, zppix e megadev44s.mail@gmail.com wrote:
I would be more than willing to help, keyword help, compile a common typo list. Just let me know and I could start up a spreadsheet or something.
Sent from my iPhone
On Nov 7, 2017, at 1:26 PM, Chad innocentkiller@gmail.com wrote:
On Tue, Nov 7, 2017 at 10:45 AM Faidon Liambotis faidon@wikimedia.org wrote:
On Tue, Nov 07, 2017 at 11:19:57AM -0700, Bryan Davis wrote: We could probably add checks for some common ones if someone compiled a
list.
Running a full spell check would be difficult because of the number of false positives there would be based on a "normal" dictionary. Commit messages often contain technical jargon (maybe something to try and avoid) and snippets of code (e.g. class names like TemplatesOnThisPageFormatter) that would not be in any traditional dictionary that we could count on being on the local host.
Debian's lintian (lint tool for packages) has a check for common typos/misspellings in its informational mode. The package ships with /usr/bin/spellintian which is a simple spellchecker that can run independently.
The benefit of using spellintian over e.g. aspell is that it addresses the issues you already identified: a) it just identifies typos, not complaining on unknown words it doesn't know, b) it's been created from observing typos in source code and package descriptions in the wild, so it's tailored to technical jargon and their misspellings. It could be a good fit to git commit messages.
That doesn't mean it's free of false positives though, so I wouldn't recommend to use it in a voting check in a CI pipeline.
Plus, you know, intentional misspellings:
"Fix misspelling of wikinedia -> wikimedia"
-Chad _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There is the file "typos" in the operations/puppet repo:
https://github.com/wikimedia/puppet/blob/production/typos
There is an existing CI check that checks against words in that fil. If you know common typos you can just add them to that file.
This could probably be copied from ops/puppet to another repos the same way.
wikitech-l@lists.wikimedia.org