This also affects 'git bash' which is just Cygwin with a different name.

When using gitlint on Cygwin, it will hang when trying to determine whether there is data being passed via stdin.

# This hangs
gitlint
# Note that Other commands do work, like:
gitlint --version
gitlint generate-config
gitlint install-hook

The issue here is with how Cygwin emulates a shell in windows. In particular, in the testing I've done, stdin is always a named pipe during gitlint invocation.

# Returns True in Cygwin, False everywhere else
python -c "import sys; import os; import stat; print stat.S_ISFIFO(os.fstat(sys.stdin.fileno()).st_mode)"

The issue with this is that once gitlint thinks that stdin is a pipe, it will then attempt and fail to read the stdin(), indefinitely waiting (i.e. gitlint hangs).

The relevant code is here:

The only way to work around this right now is actually pass data to stdin, like so:

git log -1 --pretty="%B" | gitlint

I did a bit of research into this and identified a few potential workarounds that need more investigation:

1. Detect CYGWIN environment and print a warning message. The only way to reliably detect cygwin seems to try to read the output of the uname command. Python's platform module will NOT consistently report correctly on Cygwin (if python was installed system-wide outside of Cygwin, platform will report Windows and not Cygwin).
2. Attempt implementing non-blocking reads on windows: https://stackoverflow.com/questions/34504970/non-blocking-read-on-os-pipe-on-windows
3. Still find a different way to detect that data is not being piped into gitlint, or somehow fix what stat.S_ISFIFO returns by finding/making an environment change in Cygwin.

Some additional pointers that might be relevant:

• http://cygwin.1069669.n5.nabble.com/Why-is-stdin-always-a-pipe-td141695.html
• https://stackoverflow.com/questions/41144737/python-input-does-not-detect-eol-in-mingw-terminal-but-does-in-cmd-terminal

For example, gitlint --commits HEAD~2 isn't correctly handled: it only lints the first commit in that range instead of all. This is because we are checking for the presence of dots in the refspec and if not present, add an additional--max-count argument when invoking git, see here: https://github.com/jorisroovers/gitlint/blob/master/gitlint/git.py#L127-L131

I think instead we will most likely have to add an additional check for the number of commits in the repository to correctly handle the refspec format.

CC: @tommyip

It's great having client-side validation, but let's face it some developers will simply forget or be too lazy to set it up, and then they'll submit bad commits for review regardless. So ideally there should be a way to enforce validation server-side. Of course the implementation depends on the server in question, but GitHub might be a good place to start. For example might it be possible to create a GitHub third-party service which runs gitlint server-side whenever a PR is submitted / updated, and then updates a status check on the PR accordingly?

See also codeclimate/spec#45 (allow analysis of commit messages)

When I attempt to commit via SourceTree rather than the CLI, I get:

git -c diff.mnemonicprefix=false -c core.quotepath=false -c credential.helper=sourcetree commit -q -F /var/folders/0m/_txwwtzj7sz411brd78rlbv80000gp/T/SourceTreeTemp.uRlEZw 
.git/hooks/commit-msg: line 11: /dev/tty: Device not configured
Completed with errors, see above

Any way to fix (or just suppress/ignore) that?

We just re-enabled gitlint at Zulip and a lot of our new students (we are participating in Google Code-in) who aren't comfortable with regex are confused by our ^(.+:\ )?[A-Z].+\.$ rule.

I was thinking if gitlint could show a user-defined note explaining their project's commit title style? I guess we only want to show it once if title-match-regex failed >= 1 time.

I could implement this if you are ok with the proposed feature.

Hi,

as explained in the pull request #49 we would like to package gitlint for Debian.

Here is the related "intend to package" (ITP) bug: https://bugs.debian.org/886864

The package was uploaded by @bdrung to the Debian NEW queue:
https://ftp-master.debian.org/new.html (search for gitlint)
Or use: https://ftp-master.debian.org/new/gitlint_0.9.0-1.html

@jorisroovers I would like to use this ticket for a conversation regarding the Debian packaging.

Thanks.

When debug is enabled via the config file and not via the cli convenience flag, no debug output is shown.

# No debug output
echo -e "[general]\ndebug=True" > /tmp/.gitlint
gitlint --config /tmp/.gitlint
# No debug output

Given how the debug code is structured, this will also be true for specifying debug using gitlint -c general.debug=True

Command

$ gitlint --commits upstream/master...HEAD

where upstream/master and HEAD is the same commit.

Error

...
...
File "/home/tommy/Documents/gitlint/gitlint/cli.py", line 114, in lint
    last_commit = gitcontext.commits[-1]
IndexError: list index out of range

Solution

Either just tell the user there is no commit in the range or lint the HEAD commit. I prefer the second option but some user might find that inconsistent with how Git's range work.

One can in theory just pass each commit into gitlint in a shell loop or something, but since Python initialization is somewhat slow, it'd be significantly faster and cleaner if one could do e.g. gitlint origin/master..HEAD and have it lint all the commits in that series.

Following the docs, in my .pre-commit-config.yaml I have:

-   repo: https://github.com/jorisroovers/gitlint
    rev:  master
    hooks:
    -   id: gitlint

Upon doing a git commit -a I get:

 λ git commit -a
[INFO] Initializing environment for https://github.com/jorisroovers/gitlint.
[INFO] Installing environment for https://github.com/jorisroovers/gitlint.
[INFO] Once installed this environment will be reused.
[INFO] This may take a few minutes...
black....................................................................Passed
gitlint..................................................................Failed
hookid: gitlint

2: B4 Second line is not empty: "from unittest.mock import patch"
... many more lines ...

That line is from the source file I changed as part of the commit, rather than the commit message (in fact I'm never dropped into an editor to create a commit message).

What am I missing in the config? I don't want gitlint to run over the code that's changed in the commit, but rather my commit message.

$ gitlint

$ gitlint </dev/null
1: UC2 Body does not contain a 'Signed-Off-By' line
1: UC3 Title does not follow <subsystem>: <subject>
3: B6 Body message is missing

There are many cases (e.g. automated checks) where stdio is not attached to tty (and e.g. --commits is to be used), where it would be nice that this worked; current workaround is script -ec 'gitlint' (works when linux script(1) is new enough to know -e option).

Looks like current HEAD (b054219) has some changes which shows where this problem occurs, it looks these changes do not fix this issue.

Hi there 👋 Thank you for providing this amazing project to the community!

I recently stumbled upon a disturbing issue: we cannot define multiple ignore-by-title sections in the .gitlint configuration. It means that I cannot define different rules to ignore given a particular regex.

Did I missed something?
Is this a limitation of the ini/cfg format?

Some good bug fixes since the last release. Would be great to see a v0.11.0 release that could be packaged.
v0.10.0...master

The integration tests don't run on windows since they depend on sh.

To run the tests (without ./run_tests.sh which is a bash script):

pytest -rw -s qa/

To fix this, we should implement the same sh mock library that in the integration tests that we did for the main gitlint codebase.

This occurred recently during a PR:
#10

Travis CI failure:
https://travis-ci.org/jorisroovers/gitlint/jobs/123068718

I would love to use gitlint with commits in Russian but it counts line sizes in bytes instead of characters. Other programs count characters (vim-git and Gitlab, to name a few).

Hi, thanks for this package!

I have a question: what is the best way to integrate this library with http://pre-commit.com/ ?
Thanks!

There are plans to add some sort of rule based commit ignoring?

We are using maven and the release precess add commits with messages like:

[maven-release-plugin] prepare for next development iteration

Or

[maven-release-plugin] prepare release <tag>

I can modify maven configuration to include a gitlint-ignore: all but thats really not the best solution IMO.

The idea was something in the line of author, title or body ignore rule, if the commit match that rule then is not processed.

We use fixup/squash commits during PRs, and they should always be squashed before merging. It's not uncommon to forget to do that and end up with fixups in the permanent history, though. Setting general.ignore-fixup-commits=false is not adequate for preventing the presence of fixups before merge because gitlint will still pass if they meet all commit criteria. I would like to request a way to have gitlint fail if even well-formed fixup/squash/other WIP/TODO commits are detected (if there isn't already a way to do that).

When using a current git version, the test_target fails. Obviously, its check for specific git error string is too strict.

user@debian-sid:~$ git --version
git version 2.19.0
user@debian-sid:~$ cd gitlint
user@debian-sid:~/gitlint$ git describe --tags
v0.10.0-3-gc9db6a0
user@debian-sid:~/gitlint$ git status --ignored
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
user@debian-sid:~/gitlint$ virtualenv --quiet .venv
user@debian-sid:~/gitlint$ source .venv/bin/activate
(.venv) user@debian-sid:~/gitlint$ pip install --quiet -r requirements.txt -r test-requirements.txt -r doc-requirements.txt
python-coveralls 2.9.0 has requirement coverage==4.0.3, but you'll have coverage 3.7.1 which is incompatible.
(.venv) user@debian-sid:~/gitlint$ python setup.py develop &>/dev/null && echo ok
ok
(.venv) user@debian-sid:~/gitlint$ ./run_tests.sh
### PYTHON (Python 3.6.7rc1, /home/user/gitlint/.venv/bin/python) ###
Cleaning the site, build, dist and all __pycache__directories...DONE
=============================================================================================== test session starts ===============================================================================================
platform linux -- Python 3.6.7rc1, pytest-3.0.4, py-1.6.0, pluggy-0.4.0
rootdir: /home/user/gitlint, inifile: 
collected 115 items 

gitlint/tests/test_cli.py ..................F.....
gitlint/tests/test_display.py ..
gitlint/tests/test_git.py ...............
gitlint/tests/test_hooks.py .....
gitlint/tests/test_lint.py ..........
gitlint/tests/test_options.py ......
gitlint/tests/config/test_config.py .........
gitlint/tests/config/test_config_builder.py .........
gitlint/tests/config/test_config_precedence.py ...
gitlint/tests/rules/test_body_rules.py ........
gitlint/tests/rules/test_configuration_rules.py ..
gitlint/tests/rules/test_meta_rules.py ..
gitlint/tests/rules/test_title_rules.py .......
gitlint/tests/rules/test_user_rules.py .............

==================================================================================================== FAILURES =====================================================================================================
______________________________________________________________________________________________ CLITests.test_target _______________________________________________________________________________________________

self = <gitlint.tests.test_cli.CLITests testMethod=test_target>, _ = <MagicMock name='get_stdin_data' id='140452389588216'>

    @patch('gitlint.cli.get_stdin_data', return_value=False)
    def test_target(self, _):
        """ Test for the --target option """
        os.environ["LANGUAGE"] = "C"
        result = self.cli.invoke(cli.cli, ["--target", "/tmp"])
        # We expect gitlint to tell us that /tmp is not a git repo (this proves that it takes the target parameter
        # into account).
        self.assertEqual(result.exit_code, self.GIT_CONTEXT_ERROR_CODE)
        expected_path = os.path.realpath("/tmp")
>       self.assertEqual(result.output, "%s is not a git repository.\n" % expected_path)
E       AssertionError: "An error occurred while executing '/usr/[98 chars]t'\n" != '/tmp is not a git repository.\n'
E       - An error occurred while executing '/usr/bin/git log -1 --pretty=%H': b'fatal: not a git repository (or any of the parent directories)	: .git'
E       + /tmp is not a git repository.

gitlint/tests/test_cli.py:359: AssertionError
====================================================================================== 1 failed, 114 passed in 1.14 seconds =======================================================================================
Name                 Stmts   Miss  Cover   Missing
--------------------------------------------------
gitlint/__init__         1      0   100%   
gitlint/cli            168     10    94%   20-22, 66, 117-125
gitlint/config         203      0   100%   
gitlint/display         27      2    93%   10-11
gitlint/git            103      0   100%   
gitlint/hooks           35      0   100%   
gitlint/lint            62      0   100%   
gitlint/options         68      0   100%   
gitlint/rules          228      0   100%   
gitlint/user_rules      60      0   100%   
gitlint/utils           11      1    91%   21
--------------------------------------------------
TOTAL                  966     13    99%   

### OVERALL STATUS: FAILURE ###

When using a template, gitlint lints over the whole template and not only the commit message.

Proposed fix: Filter out all lines in the template by ignoring all lines beginning with # and coming after ---- >8 ----

in: gitlint/files/commit-msg

replacing:

run_gitlint(){
   echo "gitlint: checking commit message..."
   python -m gitlint.cli --msg-filename "$1"
   gitlint_exit_code=$?
}

with:

run_gitlint(){
   echo "gitlint: checking commit message..."
   sed -n '/---- >8 ----/q;p' .git/COMMIT_EDITMSG | egrep -v '(^#)' | gitlint
   gitlint_exit_code=$?
}

seems to work with the following .gitlint file:

# All these sections are optional, edit this file as you like.
[general]
ignore=title-trailing-punctuation, T3, title-max-length, T1, body-hard-tab, B3, B1
# verbosity should be a value between 1 and 3, the commandline -v flags take precedence over this
verbosity = 3
# By default gitlint will ignore merge commits. Set to 'false' to disable.
ignore-merge-commits=true
# Enable debug mode (prints more output). Disabled by default
debug = false

# Set the extra-path where gitlint will search for user defined rules
# See http://jorisroovers.github.io/gitlint/user_defined_rules for details

[title-max-length]
line-length=50

[title-must-not-contain-word]
# Comma-separated list of words that should not occur in the title. Matching is case
# insensitive. It's fine if the keyword occurs as part of a larger word (so "WIPING"
# will not cause a violation, but "WIP: my title" will.
words=wip

[title-match-regex]
# python like regex (https://docs.python.org/2/library/re.html) that the
# commit-msg title must be matched to.
# Note that the regex can contradict with other rules if not used correctly
# (e.g. title-must-not-contain-word).
# Implement title matching according to document "Commit Message Format" in
# Google Drive
regex=^((feat|fix|refactor|chore|docs|style|test):)(\s([^:]+):)?(\s+)(.+)$

[body-max-line-length]
# B1 = body-max-line-length
line-length=72

[body-min-length]
min-length=20

[body-is-missing]
# Whether to ignore this rule on merge commits (which typically only have a title)
# default = True
ignore-merge-commits=false

[body-changed-file-mention]
# List of files that need to be explicitly mentioned in the body when they are changed
# This is useful for when developers often erroneously edit certain files or git submodules.
# By specifying this rule, developers can only change the file when they explicitly reference
# it in the commit message.
#files=gitlint/rules.py,README.md

Because of https://github.com/jorisroovers/gitlint/blob/master/gitlint/hooks.py#L7 being hard-coded as .git/hooks, the install-hooks command doesn't seem to work when using git worktrees. Worktrees keep all of their hooks in the main repository folder.

When running the integration tests in the vagrant box (./run_tests_.sh -i) from a virtualenv (e.g. .venv27 on the vagrant box), the qa/test_hooks.py file will actually use the system-wide python installation. This is because the commit-msg hook shell script contains python -m gitlint.cli which won't use the currently active virtualenv.

See

This should be fixed because now developers have the impression that the integration tests for the gitlint hooks are ran against all the python virtualenvs, while in reality they're only ran against the systemwide python installation.

I have configured body length in the following way:

[body-min-length]
min-length=5

When I test gitlint with a commit message that is exactly 5 characters, I get the following validation error:

3: B5 Body message is too short (5<5)

Shouldn't the commit be valid, if the body consists of exactly 5 characters?

As discussed in #42 and #52, there seem to be problems with the automatic check for data passed in via STDIN and the fallback to using the local repo. As it appears hard to fix, and some of the proposed (and implemented) fixes only fix the problem for certain CI configurations, I would suggest to add a command line option --use-repo (and/or a config file flag) that forces the use of the local repo and ignores any data from STDIN. This would make use in any CI environment and configuration (however proven or obscure that particular one might be) much easier and fool-proof.

This seems like a boring and simple solution to an apparent otherwise difficult-to-solve problem (see above linked issue).

What do you think @jorisroovers?

I just came across gitlint via searching for a golang implementation of https://conventional-changelog.github.io/commitlint/#/, which validates against the https://www.conventionalcommits.org/en/v1.0.0-beta.3/ spec.

It looks like gitlint is pretty configurable; I was wondering whether anyone had created a .gitlint config that made it validate against the CC spec? If not - would one be welcome?

(I'd prefer to use a golang based tool, personally, since the environment is simpler to deploy and maintain for engineers - copy a binary, run it, vs maintain a node and npm setup.)

When using git commit --fixup=<commitid>, some gitlint violations are triggered:

$ git commit -a --fixup=HEAD
gitlint: checking commit message...
3: B6 Body message is missing
-----------------------------------------------
gitlint: Your commit message contains the above violations.
Continue with commit anyways (this keeps the current commit message)? [y(es)/n(no)/e(dit)] 

Probably the B6 check should ignore commits whose title starts with fixup! ?

./run_tests doesn't work on windows since it's a bash script, but you can still run the unit tests directly using pytest:

pytest -rw -s gitlint

At the time of writing, 35 unit tests are failing, 94 are passing. Some failures seem related to unicode issues.

Currently gitlint can only take a directory as argument for extra rules gitlint --extra-path=<path>, would it make sense to also support only filenames?

Supposing I run git commit and write a longish message (e.g. a couple of paragraphs in the body) using my editor of choice. There's an error though, I've left a trailing period in the first line.

Continue with commit anyways (this keeps the current commit message)? [y/n]

If I answer 'n' to that, next time I commit I've lost all my original text. If someone chooses n, could you print the full message they entered underneath so they can copy and paste it back into the editor?

(Unless you think the correct action is to commit anyway and then amend it.)

We currently only apply the commit-specific config of the last commit, not of every commit in the specified range. The following code block needs to be moved to the for-loop below it:
https://github.com/jorisroovers/gitlint/blob/master/gitlint/cli.py#L127-L131

CC: @tommyip

Installed gitlint with pre-commit following the doc, and it doesn't work.

(py37) ➜  workspace git:(develop) ✗ git commit -m 'testlkasdklnalgklkwamglamweoingienibgblalsjkdlgjldjlgasdgfasdfasdfasdgwebbffsdfsdnsdfsgwrqwrqwr'
autopep8.................................................................Passed
Check for added large files..............................................Passed
Check JSON...............................................................Passed
Check for merge conflicts................................................Passed
Check Yaml...............................................................Passed
Fix End of Files.........................................................Passed
Flake8...................................................................Passed
Fix requirements.txt.....................................................Passed
Don't commit to branch...................................................Passed
Trim Trailing Whitespace.................................................Passed
[develop (root-commit) 8ae7eec] testlkasdklnalgklkwamglamweoingienibgblalsjkdlgjldjlgasdgfasdfasdfasdgwebbffsdfsdnsdfsgwrqwrqwr
 17 files changed, 825 insertions(+)

When run pre-commit run gitlint, I got:

No hook with id `gitlint`

Here is my .pre-commit-config.yaml:

repos:

-   repo: https://github.com/pre-commit/mirrors-autopep8
    rev: v1.4.4
    hooks:
    -   id: autopep8
        args:
        - --in-place
        - --ignore=E501

-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.2.3
    hooks:
    -   id: check-added-large-files
    -   id: check-json
    -   id: check-merge-conflict
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: flake8
        args:
        - --extend-ignore=E501
    -   id: requirements-txt-fixer
        files: requirements*
    -   id: no-commit-to-branch
    -   id: trailing-whitespace
        args:
        - --markdown-linebreak-ext=md

-   repo: https://github.com/jorisroovers/gitlint
    rev:  master
    hooks:
    -   id: gitlint
 

gitlint can read configuration options from .gitlint. Is it possible add feature for reading options from setup.cfg and tox.ini?

For example flake8 can read configuration options from .flake8, setup.cfg, or tox.ini files. It is very convenient

I get this error on a Vagrant box using Ubuntu 14.04.3 LTS (and because it's in a while loop it was printed over and over again.)

I removed the -e switch from line 24 and gitlint seemed to work correctly but I haven't been able to find anything which specifies what -e is supposed to do?

Hi,
I am looking for your supporting.
I have following error below:
OS: Ubuntu 16.04
Python version: 2.7.12
pip version: 9.0.1

After I run pip install gitlint there are following error below relate to permission.

Exception:
Traceback (most recent call last):
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/basecommand.py", line 215, in main
    status = self.run(options, args)
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/commands/install.py", line 342, in run
    prefix=options.prefix_path,
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/req/req_set.py", line 784, in install
    **kwargs
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/req/req_install.py", line 851, in install
    self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/req/req_install.py", line 1064, in move_wheel_files
    isolated=self.isolated,
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/wheel.py", line 345, in move_wheel_files
    clobber(source, lib_dir, True)
  File "/home/sakona/.local/lib/python2.7/site-packages/pip/wheel.py", line 323, in clobber
    shutil.copyfile(srcfile, destfile)
  File "/usr/lib/python2.7/shutil.py", line 83, in copyfile
    with open(dst, 'wb') as fdst:
IOError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/sh.py'

Thanks for your support and give suggestion.

Adding features to gitlint (or improving existing ones) is unfortunately pretty difficult due to intermittently failing integration tests. This can also be seen in simple pull requests such as #73.

I tried a few things in #76, but haven't been able to fix it so far.

My feeling is that it is related to unicode string handling, possibly also in connection with an outdated version of sh that returns the strings that are compared to the reference result. The sh changelog shows quite a few unicode-related bugs being fixed in versions newer than the one currently used by gitlint. Those newer versions appear to be incompatible with gitlint today, so simply updating the dependency is not enough.

The gitlint commit-msg hook works fairly well on windows when the user has git bash (i.e. Cygwin) installed, with the exception of re-editing the message after gitlint raises violations.

When gitlint re-opens the editor (e.g. vim), there are some serious issues with the text editor. This is likely because of how gitlint and git pass data to each-other during this interaction.

While we can look into solving this particular issue, it's probably better to just re-implement the commit-msg in python itself as opposed to using a bash script. This will improve cross-platform compatibility and also make it easier to maintain and test the hook.

Users 'should' be able to use pre-commit as a work-around, but this has not been tested.

The exit code of gitlint represents the number of found violations (up to 252) as documented here : http://jorisroovers.github.io/gitlint/#exit-codes

When linting multiple --commits, gitlint returns the number of violations found in the last commit message, not e.g. the total count of violations in all linted messages. This is especially problematic in case there are no violations in the last linted commit message as gitlint will exit with an exit code of 0, even though violations might have been found in other commits. This breaks CI scripts depending on the exit code.

Can I use gitlint as a pre-push hook? It matched some unexpected data:

$ git push origin gitlint
1: T1 Title exceeds max length (119>72): "refs/heads/gitlint 28532b3925ae8c54af2d0012638688e4f1cfd203 refs/heads/gitlint 0000000000000000000000000000000000000000"
1: T7 Title does not match regex (.*\.$): "refs/heads/gitlint 28532b3925ae8c54af2d0012638688e4f1cfd203 refs/heads/gitlint 0000000000000000000000000000000000000000"
error: failed to push some refs to '[email protected]:gaul/repo.git'

When using gitlint on Jenkins it doesn't work as it does locally simply by executing "gitlint" to check the latest commit.

gitlint

Since on Jenkins there is not tty present the command simply fails with several cryptical warnings (probably because stdin is empty). When using the -d option it tells me DEBUG: gitlint.lint Linting commit [SHA UNKNOWN] which was even more confusing.

After reading the code and re-reading the documentation I ended up sucessfully using this:

git log -1 --pretty=%B | gitlint

This is a little cumbersome and it seems unecessary to base the decision whether to perform GitContext.from_local_repository depending on if there is a TTY present or not.

Suggestions:

• Always use from_local_repository if there is a local repository AND (stdin is empty OR not tty). Use stdin in other cases.
• Alternatively or additionally document this more clearly. Maybe a doc section on how to use gitlint with CI tools.

In case of failure please display the whole message, so I can copy-n-paste it next time (and not to start typing over and over again)...

My specific usecase is to use gitlint to lint commit messages which should follow the GNU Change Log guidelines (https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs).

These commit messages are run through a script which converts git log entries to a ChangeLog file for distribution.

One of the requirements of the ChangeLog is that every commit explicitly lists out all the files which were modified in that commit. So, I'd like for body-changed-file-mention to run for every single file in the git repository. A simple way to do that would be to allow the rule to be a regex, so that .* will cause the rule to be executed for all files.

Thanks for writing gitlint @jorisroovers, it's really helpful! Are there any blockers to releasing 0.9.0 to PyPI? I have commit.verbose = true set in my global Git configuration, so it would be great to have a new release that includes the changes merged in #34.

i really like the gitlint program and i would love to use it in my pre-commit chain. i configured it like in the docs. i just dont get it how it works. how can it check the commit message if its tested pre-commit? do i need to add the commit message to a txt file?

80 chars is the standard for writing code, but Tim Pope's authoritative guide recommends wrapping Git commits at 72. The community has largely agreed on this standard; the Pro Git book mentions it too.

When running gitlint --commits $REFS where $REFS is a range of hashes, the program returns an exit status corresponding to the final commit in the range and ignores any earlier errors encountered.

When trying to install on windows 7 with python 2.7.11 - I got following error trace:

Collecting gitlint
  Using cached gitlint-0.8.0-py2.py3-none-any.whl
Collecting sh==1.11 (from gitlint)
  Using cached sh-1.11.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "c:\users\admin\appdata\local\temp\pip-build-q_3wmy\sh\setup.py", line 4, in <module>
        import sh
      File "sh.py", line 37, in <module>
        support." % __version__)
    ImportError: sh 1.11 is currently only supported on linux and osx. please install pbs 0.110 (http://pypi.python.org/pypi/pbs) for windows support.
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in c:\users\admin\appdata\local\temp\pip-build-q_3wmy\sh\

Installation of pbs 0.110 did not help to resolve the issue - same error occurs