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:
- 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.
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.
- Custom via Jpegtran
- Via python json.tool module
- Custom via PyYAML
- Custom via ConfigParser module
- PMD (it requires to put the script run.sh in your PATH)
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:
- %(REPO_HOME)s: the root of your repo.
- %(DEFAULT_CONFIGS)s: the location of the default config files.
Python 2.7 is supported, and it should also work for Python 3.2 and 3.3. Python 2.6 is not supported because of the lack of subprocess.check_output.
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.
Adding a linter
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.)
TODOS and Possible Features
- Add travis-ci configuration for e2e tests.
- Replace mock calls in test with pyfakefs.
- Linter that uses libmagic to validate that the extension is correct. Many times I’ve seen that an image, or a compressed file has the wrong extension.
- Normalize output. That is, try to uniform the output, by removing the filename and strings like ‘line’ or ‘col’.
- When multiple linters are available sort the output of the linters by line
- Support directories as arguments
- Provide a way to install as a precommit hook
- Provide 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 other version control systems like mercurial. This should be easy, it’s just a matter of implementing the functions defined in gitlint/git.py.
- Support windows.
- Added linters: ruby-lint, rubocop, checkstyle, pmd
- Variables %(REPO_HOME)s and %(DEFAULT_CONFIGS)s can be specified in configuration
- Added default pylintrc configuration
- Added linters: html, tidy, scss
- Added way to override default configuration
- Improvements for Python3
- Fixes to the filter syntax
- Fixes to the git parser
- Added 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.
- Fixes to the installer
- Initial commit with the basic functionalities. Released mainly to collect feedback about the features and the planned ideas.