Comments on “Ignore Git's Suspicious Patch Lines”

Ignore Git's Suspicious Patch Lines

2010-06-01T00:22:52-04:00

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”, $_); } }

Ignore Git's Suspicious Patch Lines

2010-05-26T18:45:33-04:00

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

Ignore Git's Suspicious Patch Lines

2010-04-23T15:56:31-04:00

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)

Ignore Git's Suspicious Patch Lines

2009-10-16T14:01:18-04:00

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?!?

Ignore Git's Suspicious Patch Lines

2008-09-14T22:53:36-04:00

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

Ignore Git's Suspicious Patch Lines

2008-09-13T15:32:39-04:00

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