Package: git-lint
Git-LintGit-lint is a tool for improving source code one step at a time.MotivationOften times enforcing coding styles to an existing project can be a nightmare.
Some reasons may include:the codebase is already a mess and the output of the tools is overwhelming.developers don’t feel confident changing lines they do not own.or they just don’t know what tool to use.FeaturesThis 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:CSSCsslintSCSSscss-lintPythonPylintpycodestylePHPPhp Code SnifferJavascriptJshintGjslintJPEGCustom viaJpegtranPNGCustom viaPngcrushCustom viaOptipngRSTViarst2html.py (docutils)JSONVia pythonjson.tool moduleYAMLyamllintINICustom viaConfigParser moduleHTMLHTML-LinterTidywith preprocessing fromtemplate-removerRubyruby-lintrubocopJavaPMD(it requires to put the script run.sh in your PATH)CheckstyleCoffeescriptcoffeelintC++cpplintExample useBelow 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.InstallationYou can install, upgrade or uninstall git-lint with these commands:$ pip install git-lint
$ pip install --upgrade git-lint
$ pip uninstall git-lintConfigurationGit-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.yamlin the root of your repository. You can copy
the filehttps://github.com/sk-/git-lint/blob/master/gitlint/configs/config.yamlto 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:{REPO_HOME}: the root of your repo.{DEFAULT_CONFIGS}: the location of the default config files.If you need to include strings like{}or{foo}in your command, you need to
double the braces as in{{}}or{{foo}}.Git Configurationgit-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-commitor if you want to install it globally execute instead:$ ln -s `which pre-commit.git-lint.sh` /usr/share/git-core/templates/hooks/pre-commitMercurial ConfigurationTo 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 asrebaseorshelve.LimitationsIn 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 VersionsPython 2.7 is supported, and it should also work for Python 3.2, 3.3 and 3.4.
Python 2.6 is not supported because of the lack of subprocess.check_output.DevelopmentHelp for this project is more than welcomed, so feel free to create an issue or
to send a pull request viahttp://github.com/sk-/git-lint.Tests are run using nose, either with:$ python setup.py nosetests
$ nosetestsThis same tool is run for every commit, so errors and style problems are caught
early.Adding a linterJust 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.)TODOS and Possible FeaturesSupport directories as argumentsProvide a man page so ‘git help lint’ and ‘git lint –help’ work. I already
have a script for converting the Usage to a man page, but I still need to
figure out how to install it on the system.Allow to run a command or function when setting up the linter? These can be
achieved now by running a bash script wrapping the linter. The rationale for
this is that some linters, like jshint, only allow options to be in a
configuration file. This is done at the moment via scripts present in the
folder linters.Decide what linter to use based on the whole filename or even in the filetype,
as returned by the command file.Provide better options for colorizing the output, and maybe a way to disable
it. Also detect if colors are supported or if it is a tty.Add support for more version control systems (svn, perforce). This should be
easy, it’s just a matter of implementing the functions defined in
gitlint/git.py or gitlint/hg.py.Support windows.ContributorsRovanion LuckeyRadek SimkoAdrien VergéRob RodriguesAlex LordThorsenChangelogv0.1.2 (2018-05-24)Fixed race condition when creating cache directories.v0.1.1 (2018-05-15)Fixed futures dependency not working corectly in Python 3.v0.1.0 (2018-02-26)Fixed setup in some systems due to default encodings.Changed version to use semantic versioning. If the version would have been semantic, this release would have been just a patch.v0.0.9 (2018-01-22)Fixed versioning to match in both pip install and packageAdded multithreading supportv0.0.8 (2015-10-14)Fixed git pre commit hook (thanks to Rovanion Luckey)Fixed issues #64, #67v0.0.7 (2015-06-28)Better support in python 3Removed support for Python 3.2Output is sorted by line and column numberBugfixes: issues #49, #50, #54, #62Added coffelint supportImproved defaultsv0.0.6 (2014-09-08)Added mercurial supportRun e2e tests on Travisv0.0.5 (2014-05-09)Added linters: ruby-lint, rubocop, checkstyle, pmdVariables %(REPO_HOME)s and %(DEFAULT_CONFIGS)s can be specified in configurationAdded default pylintrc configurationv0.0.4 (2014-05-08)Added linters: html, tidy, scssAdded way to override default configurationImprovements for Python3v0.0.3 (2014-02-02)Fixes to the filter syntaxFixes to the git parserAdded linters (YAML, Ini, PHP) and improved linter for PNG and JPEG.Improved pylint configuration.Improved phpcs configuration.Check if program is available and if not display info to install it.Cache the output of linters, so subsequent calls are much faster.v0.0.2 (2013-10-20)Fixes to the installerv0.0.1 (2013-10-20)Initial commit with the basic functionalities. Released mainly to collect
feedback about the features and the planned ideas.