Incorrect commit message parsing for git versions < 1.7.2

(venv)vagrant@vagrant-amooney:DEVELOPMENT:current> gitlint --version
gitlint, version 0.8.2

(venv)vagrant@vagrant-amooney:DEVELOPMENT:current> git log -1
commit b0be6977c6fb474b3ca270fffb0485f17bfb48c4
Author: Alex Mooney <[e-mail]>
Date:   Thu Apr 27 14:44:10 2017 -0400

    This title is a reasonable length

    Oh man though, this body? It just keeps going forever on one line as if someone with a substandard editor wrote it. It is, like, crazy long with no line breaks at all.

(venv)vagrant@vagrant-amooney:DEVELOPMENT:current> gitlint --debug
config-path: /vagrant/code/claims/.gitlint
[GENERAL]
extra-path: None
ignore: body-is-missing
ignore-merge-commits: True
verbosity: 3
debug: True
target: /vagrant/code/claims
[RULES]
  T1: title-max-length
     line-length=72
  T2: title-trailing-whitespace
  T6: title-leading-whitespace
  T3: title-trailing-punctuation
  T4: title-hard-tab
  T5: title-must-not-contain-word
     words=WIP
  T7: title-match-regex
     regex=.*
  B1: body-max-line-length
     line-length=80
  B5: body-min-length
     min-length=20
  B6: body-is-missing
     ignore-merge-commits=True
  B2: body-trailing-whitespace
  B3: body-hard-tab
  B4: body-first-line-empty
  B7: body-changed-file-mention
     files=

DEBUG: gitlint.lint Linting commit b0be6977c6fb474b3ca270fffb0485f17bfb48c4
DEBUG: gitlint.cli Exit Code = 0

[jorisroovers]

I did some more digging into this.

For future reference, this is the official spec from https://git-scm.com/docs/pretty-formats

'%b': body
'%B': raw body (unwrapped subject and body)

The following answer on SO provides a slightly more detailed answer: http://stackoverflow.com/a/28820275

This %B functionality was added in git v1.7.2 in this commit https://github.com/git/git/commit/1367b12ad623e28546ba40c435015d94e7fbb248.

@AlexMooney Obviously, the easiest solution is updating to git v1.7.2 or above. Given that this particular functionality was added in git in 2010 (i.e. over 7 years ago), I don’t think that’s an unreasonable ask.

I’ll spend some more time exploring alternatives, but your example using a combination of %s and %b doesn’t work for all use-cases. In a nutshell, git determines the difference between title (%s) and body (%b) based on the first empty line it finds, while gitlint only considers the actual first line to be the title. This means for example that if you add text on the second line (which should typically be empty, gitlint enforces this), that git will still return it as part of %s.

Coding around this is definitely not unsurmountable, it’s just that I’m a little wary how this will impact different versions and distributions of git. We should obviously make sure we don’t break gitlint for anyone else 😃 My current thoughts are that we should probably keep using %B and fallback to a combination of %s and %b for git versions prior to v1.7.2.

I’m not sure when I can make time for this, it might be fairly soon, but might also take a few months (this is still a hobby project for me 😃). Appreciate any PRs, but I do think we need to discuss the exact logic a bit more before someone starts digging in.

[jorisroovers]

Yes, that’s exactly what I had in mind at this point and why I’ve kept this open 👍