Unfortunately I've decided to deprecate this package.
git-lint would be more valuable to large companies with large legacy codebases. But for smaller ones, it's quite possible (I've done it in many) to progressively make the linter config stricter. git-lint, but at least would lint only modified files. .. image:: https://badge.fury.io/py/git-lint.svg :target: http://badge.fury.io/py/git-lint
.. image:: https://travis-ci.org/sk-/git-lint.svg?branch=master :target: https://travis-ci.org/sk-/git-lint
.. image:: https://coveralls.io/repos/sk-/git-lint/badge.svg?branch=master :target: https://coveralls.io/r/sk-/git-lint?branch=master
Git-lint is a tool for improving source code one step at a time.
Often times enforcing coding styles to an existing project can be a nightmare. Some reasons may include:
This tool tackles all the 3 problems mentioned above by providing just a single tool that lints all the modified files. For each filetype it may use even more than one linter or tool. Furthermore by default it only report problems of lines that were added or modified.
Current linters:
CSS
Csslint <https://github.com/stubbornella/csslint>_SCSS
scss-lint <https://github.com/causes/scss-lint>_Python
Pylint <http://www.pylint.org/>_pycodestyle <https://github.com/PyCQA/pycodestyle>_PHP
Php Code Sniffer <http://pear.php.net/package/PHP_CodeSniffer/>_Javascript
Jshint <http://www.jshint.com/>_Gjslint <https://developers.google.com/closure/utilities/>_JPEG
Jpegtran <http://manpages.ubuntu.com/manpages/raring/man1/jpegtran.1.html>_PNG
Pngcrush <http://manpages.ubuntu.com/manpages/raring/man1/pngcrush.1.html>_Optipng <http://manpages.ubuntu.com/manpages/raring/man1/optipng.1.html>_RST
rst2html.py (docutils) <http://docs.python.org/2/library/json.html>_JSON
json.tool module <http://docs.python.org/2/library/json.html>_YAML
yamllint <https://github.com/adrienverge/yamllint>_INI
ConfigParser module <http://docs.python.org/2/library/configparser.html>_HTML
HTML-Linter <https://github.com/deezer/html-linter>_Tidy <https://w3c.github.io/tidy-html5/> with preprocessing from template-remover <https://github.com/deezer/html-linter>Ruby
ruby-lint <https://github.com/yorickpeterse/ruby-lint>_rubocop <https://github.com/bbatsov/rubocop>_Java
PMD <http://pmd.sourceforge.net/>_ (it requires to put the script run.sh in your PATH)Checkstyle <http://checkstyle.sourceforge.net/>_Coffeescript
coffeelint <http://www.coffeelint.org/>_C++
cpplint <https://github.com/google/styleguide/tree/gh-pages/cpplint>_Below is the simplest call, for a detailed list, see the help::
$ git lint Linting file: src/html/main.js Line 13, E:0110: Line too long (328 characters). Line 31, E:0001: Extra space at end of line src/html/main.js: line 75, col 11, ['location'] is better written in dot notation.
Linting file: src/html/main.css src/html/main.css: line 1, col 135, Warning - Duplicate property 'margin' found.
Linting file: api.py api.py:6: [C0301(line-too-long), ] Line too long (87/80) api.py:6: [R0913(too-many-arguments), callMethod] Too many arguments (6/5) api.py:6: [C0103(invalid-name), callMethod] Invalid function name "callMethod"
By default git lint only reports problems with the modified lines (with the exception of some linters that check that the whole file is sound). To force displaying all the output from the linters use the -f option.
You can install, upgrade or uninstall git-lint with these commands::
$ pip install git-lint $ pip install --upgrade git-lint $ pip uninstall git-lint
Git-lint comes with a default configuration that includes all the linters listed
above. If you don't like that list you can write your own configuration and put
it in a file called .gitlint.yaml in the root of your repository. You can copy
the file https://github.com/sk-/git-lint/blob/master/gitlint/configs/config.yaml
to your repo and modify it.
If you add a new linter or add a new flag to any of the commands, please share that with us, so we can integrate those changes.
The configuration support two variables for the command, requirements and arguments:
If you need to include strings like {} or {foo} in your command, you need to
double the braces as in {{}} or {{foo}}.
git-lint comes with a pre-commit hook for git. To install it for your repo execute::
$ ln -s which pre-commit.git-lint.sh $PATH_TO_YOUR_REPO/.git/hooks/pre-commit
or if you want to install it globally execute instead::
$ ln -s which pre-commit.git-lint.sh /usr/share/git-core/templates/hooks/pre-commit
To make available git-lint with a better name in mercurial you have to add the following to your .hgrc configuration::
[alias] lint = !git-lint $@
To add a pre-commit hook add the following::
[hooks]
pretxncommit.hglint = pre-commit.hg-lint.sh > tty
The hook above has a hack to display the output of the command. Additionally, as mercurial does not provide (AFAIK) any way to skip a hook, if you want to force a commit with linter warnings execute the commit command as follow::
$ NO_VERIFY=1 hg commit ...
Note though that mercurial heavily uses commit to leverage all of their commands/extensions.
I've found that setting any sort of precommit hook will get on your way when using common
actions as rebase or shelve.
To run git lint on Travis, you can add the following step::
git reset --soft ${TRAVIS_COMMIT_RANGE%...*} && git lint
In some cases a change will trigger a warning in another line. Those cases are unfortunately not handled by git-lint, as it only reports those lines that were modified. Fully supporting this use case would require running the linters twice and reporting only the new lines. The most common case in which this occurs is with unused imports or variables. Let's say we have the following piece of code::
import foo foo.bar()
If you remove the second line, git-lint will not complain as the warning is for line 1, which was not modified.
Python 2.7 and Python 3.5 and higher are supported.
Help for this project is more than welcomed, so feel free to create an issue or to send a pull request via http://github.com/sk-/git-lint.
Tests are run using nose, either with::
$ python setup.py nosetests $ nosetests
This same tool is run for every commit, so errors and style problems are caught early.
Just need to configure the file gitlint/config.yaml. I hope the syntax is self explanatory. (Note to myself: don't be so lazy and write a proper doc for this.)
Rovanion Luckey <https://github.com/Rovanion>_Radek Simko <https://github.com/radeksimko>_Adrien Vergé <https://github.com/adrienverge>_Rob Rodrigues <https://github.com/irialad>_Alex LordThorsen <https://github.com/rawrgulmuffins>_