A pre-commit hook that knows how to diff against files in the staging area, not the file system.
Go to file
Elf M. Sternberg 556c56fb43 Fixing links, adding documentatin. 2016-10-04 10:26:44 -07:00
bin Updating the requirements doc. 2016-10-03 12:44:57 -07:00
docs Fixed usage inclusion. 2016-10-04 10:16:17 -07:00
git_lint I ought to pass my own lint style checks, ne? 2016-10-03 12:31:01 -07:00
tests Fixed reportage matrix. 2016-10-03 12:13:35 -07:00
utils Trying to get the man page just right. 2016-09-27 10:06:01 -07:00
.editorconfig Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
.git-lint Updating the requirements doc. 2016-10-03 12:44:57 -07:00
.gitignore More development progress. 2016-09-19 15:36:58 -07:00
.travis.yml Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
AUTHORS.rst Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
CONTRIBUTING.rst Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
HISTORY.rst The staging wrapper works beautifully. 2016-09-26 15:26:04 -07:00
LICENSE Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
MANIFEST.in Fixed paths to prefix and man page. 2016-10-03 08:24:50 -07:00
Makefile Updated Makefile and setup to include the man file as part of the install. 2016-09-30 11:49:21 -07:00
README.rst Fixing links, adding documentatin. 2016-10-04 10:26:44 -07:00
requirements_dev.txt Used cookiecutter to generate a better skeleton for the project, prior 2016-09-19 14:41:01 -07:00
setup.cfg Bumping version. 2016-09-26 16:54:27 -07:00
setup.py I ought to pass my own lint style checks, ne? 2016-10-03 12:31:01 -07:00
tox.ini W00t! Working unit tests to assert things, like "That kind works" 2016-09-29 15:14:46 -07:00

README.rst

===============================
Git Lint: README
===============================

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.

Usage
-----

To lint only what's changed recently in your current working directory:
    `git lint`

To lint everything, changed or otherwise, from the current directory down:
    `git lint -a`

To lint what's changed from the repo's base:
    `git lint -b`

To lint what's in your staging directory:
    `git lint -s`


Documentation
-------------

Complete documentation for the project is available in the docs directory, or at `Git
Linter Docs <https://elfsternberg.github.io/git-linter/index.html>`_.



    
Install
-------

    `pip install git-linter`

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.


Features
--------

* 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.


Acknowledgements
----------------

`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
<https://dzone.com/articles/why-your-need-git-pre-commit>`_*, as well as just my own needs
as a software developer.


Disclaimer
----------

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.