Git Lint could always use more documentation, whether as part of the
+official Git Lint docs, in docstrings, or even on the web in blog posts,
+articles, and such.
Before you submit a pull request, check that it meets these guidelines:
+
+
The pull request should include tests.
+
If the pull request adds functionality, the docs should be updated. Put
+your new functionality into a function with a docstring, and add the
+feature to the list in README.rst.
Creates a match filter for the linter, extract the files to be
+linted, and runs the linter against each file, returning the
+result as a list of successes and failures. Failures have a
+return code and the output of the lint process.
Returns the configuration file as a dictionary of dictionaries.
+Performs substitutions as specified in the SafeConfigParser
+specification; the only one performed currently is the ‘repodir’
+will be replaced with the base directory of the repository.
+Combined with the option to specify the .git-lint configuration as
+a directory, this allows users to keep per-project configuration
+files for specific linters.
Once you have a copy of the source, you can install it with:
+
$ python setup.py install
+
+
+
Once installed, please copy the ‘.git-lint’ example file. You may install this either in
+your home directory as .git-lint or in your project’s git directory as
+.git/lint/git-lint
Runs a list of configured linters against a specified list of files in
+your repository. By default all linters will be run against the
+changed files in your current workspace, from the current working
+directory on down. Command line options let you choose a different
+directory, a different of files, the complete set of files, and even
+the files currently in the staging area.
By default, the output is that of all the linters specified, in the
+order in which they appear in the configuration file, followed by
+every file specified, sorted ASCIIbetically. This order can be
+flipped (files first, then linters) with the --byfiles option.
+
gitlint returns the maximal error code if any linters fail a
+pass, or zero if they all succeed.
gitlint uses a standard INI-style configuration file. Aside from the
+DEFAULT section, the name of each section is an alphanumeric token name for
+a linter, followed by configuration details for that linter. Standard details
+are:
+
+
output - Text to print before running a linter.
+
command - The actual command to run, minus the file path
+
match - A comma-separated list of extensions to match against the linter
+
print - If true, will prefix each line of output from the linter with the filename
+
condition - if “error”, the return code of the linter is the status of the pass. If “output,” any output will result in a failure.
+
comment - Text to include when running the --linters option
A git command that automatically runs identifiable linters against
+changed files in your current git repository or staging area.
+
+
Free software: MIT license
+
+
Git Lint runs a configurable set of syntax, style, and complexity
+checkers against changed files in your current working directory or
+staging area. It can be configured to work with any lint-like
+command. Some commands may require shell wrappers.
+
While it may be possible to create a custom lint command in your npm,
+grunt, Make, CMake, or whatever, the fact is we all use a VCS, and most
+of us use git. Having a centralized repository for what we want checked
+and how we want it checked, associated with git (and by extension, as a
+pre-commit hook), that can be run at any time for any reason.
You will need to copy the .git-lint configuration file to either your
+home directory or the repo`s base directory. Edit the configuration
+file as needed. You will also need any linters that you plan on
+running.
Highly configurable - configuration files, both for git-lint and
+individual linters, can be global or per-project.
+
Only checks files that have been changed, but this can be overriden
+from the command line.
+
Can be used directly as a pre-commit hook, to ensure you personally
+don’t check in anything broken.
+
Used this way, it checks the staging area, not your workspace.
+
When using the staging area, it stashes your current work. Upon
+restoration of your workspace, it ensures the timestamps are the
+same, so as not to confuse your build system or IDE.
Git lint started life as a simple pre-commit hook. Most of the
+changes since were inspired by Steve Pulec’s `Why You Need a Git
+Pre-Commit Hook and Why Most Are Wrong`_ , as well as just my own needs as
+a software developer.
This software, including provided configuration and documentation
+materials, is provided “as is” without any warranties, including any
+implied warranties of merchantability, fitness, performance, or
+quality. In no event shall the author or sponsor be liable for any
+special, direct, indirect, or consequential damages or any damages
+whatsoever resulting from loss of use, data or profits, whether in an
+action of contract, negligence or other tortious action, arising out
+of or in connection with the use or performance of this software.
+Each user of the program will agree and understand, and be deemed to
+have agreed and understood, that there is no warranty whatsoever for
+the program and, accordingly, the entire risk arising from or
+otherwise connected with the program is assumed by the user.
+ Please activate JavaScript to enable the search
+ functionality.
+
+
+
+ From here you can search these documents. Enter your search
+ words into the box below and click "search". Note that the search
+ function will automatically search for all of the words. Pages
+ containing fewer words won't appear in the result list.
+