Ignore Git's Suspicious Patch Lines

Posted on Friday, September 12th, 2008 at 8:29pm by Rob Wilkerson

Those who follow me on Twitter have recently been forced to endure a steady stream of rants directed at Git, the DCVS I’ve been trying out while working on the new theme for this site (one really is coming). I’ve only tweeted a fraction of my frustration, but this tweet sums it up nicely:

What the fuck is up with git and its need for precisely zero trailing whitespace?! Suspicious patch lines my ass.

It seems that Git is a finicky little bastard and it pays obscenely close attention to whitespace. If there is a line, any line, with whitespace at the end of it Git decides that something must be fishy. I mean, it’s whitespace. Horror. Everyone knows whitespace is the very spawn of Satan, right? Er, no. Nonetheless, if there’s any trailing whitespace to be found in content that’s being committed, Git balks:

*
* You have some suspicious patch lines:
*

The message then proceeds to itemize its suspicions for my viewing pleasure. Tonight I’d finally had enough. I can’t figure out how to make Git force the commit or at least stop it from worrying its pretty little head over a little empty space, so I took drastic measures:

$ sudo chmod a-x /path/to/my/repository/.git/hooks/pre-commit

That’ll teach it to mess with me.

, 6 Comments

Subscribe6 Comments on Ignore Git's Suspicious Patch Lines

  1. Jakub Narebski said...

    You can force a commit using “git commit —no-verify” (it bypasses commit hooks).

    ...on
  2. Daniel White said...

    New repositories (as of ~1.6.0) install the hooks with a .sample extension so they don’t run by default.

    ...on
  3. Alpheus said...

    Well said! I’m new to Git, and I’m liking it so far…but this is such a bizarre thing to get caught up on! It’s my understanding that the latest versions of git don’t have this problem. (I’m using Debian Lenny, so apparently my version isn’t the latest!)

    It’s an interesting idea, though: to have a script that checks for something before you commit. But why did it have to be whitespace?!?

    ...on
  4. mars said...

    As a PHP programmer, I agree with your frustration, because PHP ignores whitespace. I would guess the pre-commit hook is in there for programmers who use other languages where whitespace matters such as Python. The PEP 8 that defines the Python coding style guide (http://www.python.org/dev/peps/pep-0008/) suggests an 80 character width for all lines.

    Whether or not a restriction of 80 char/line makes any sense in this day and age, well, no comment. I’m not a Python programmer (yet) but I know enthusiasts, and they don’t seem to mind it too much.

    I’m not sure if the Python interpreter enforces the 80 char limit, but if it does, you can see where trailing whitespace might become a problem.

    This theory can be backed up by the comments found in .git/hooks/pre-commit that also check for a mixture of tabs and spaces at the beginning of lines, which I know the Python interpreter will whine about if invoked with certain options.

    Furthermore, I’m sure there are plenty of other examples where GIT is being used to version documents that require a specific number of characters per line, whitespace or otherwise (although none come immediately to mind :-)

    This is the ONLY reason I can currently think of having that particular check in the pre-commit hook. However I can think of NO reason why it is there by default.

    As for your solution, you might want to be careful by simply making pre-commit non-executable.

    For one, if you look in the actual script, there is another error there that spits the message “unresolved merge conflict”, which is decidedly more important, and I wouldn’t recommend trying to bypass it.

    Secondly, you can add your own pre-commit hooks which can be very handy sometimes.

    Personally, my workaround was just to comment out the conditional that throws the “trailing whitespace” error (in my version, it’s lines 58-60 — otherwise identifiable by the regex:

    /\s$/

    also, use # to comment in Perl which has no block commenting to my knowledge)

    ...on
  5. JOsh Beauregard said...

    I just had this problem it was due to the pre-hooks file being executable. so what you have to do is change the permissions on /.git/hooks/pre-commit to be non executable

    ...on
  6. Victor said...

    I had the same problem. I need the pre-commit hook but I just dont need the trailing space verification so I edit the pre-commit file commenting with “#” character the three lines that do the trailing space verification

    if (s/^\+//) { $lineno++; chomp; # if (/\s$/) { # bad_line(“trailing whitespace”, $_); # } if (/^\s* \t/) { bad_line(“indent SP followed by a TAB”, $_); } if (/^([<>])\1{6} |^={7}$/) { bad_line(“unresolved merge conflict”, $_); } }

    ...on