Git on Windows: “You have some suspicious patch lines”

Update 2008-04-24: as commenter Jakub Narebski correctly points out, it should be better to use core.autocrlf and crlf attribute for resolving this issue, but I have had no chance to test this up to now. The solution below is still valid, but more of the sort of an ugly hack.
Update 2008-06-11: I have stopped using this solution and only use “git-config core.autocrlf true” and “git-config core.safecrlf true” any more. It works reliably and is exactly what I need and not such an ugly hack.
Update 2008-06-22: Well, of course you can still get “You have some suspicious patch lines” if you follow the core.autocrlf approach… but this time it really means you have trailing whitespace, not just line-breaks. If you really don’t care about trailing white-space at all, my initial solution is still valid, as it simply disables this check.

If you are using Git under Windows using cygwin, and you got through the initial problems, you will soon realize that Git likes to fail with “You have some suspicious patch lines” when committing.

The cause for this problem is the carriage-return/line-feed problem of Git under Windows/cygwin: The patches contain a trailing line-feed if you edited them with a Windows editor and not strictly inside cygwin. This will trigger the pre-commit hook to fail on patches where the last line of a file has been changed.

To solve the problem, you need to edit .git/hooks/pre-commit and comment out the following lines:

if (/\s$/) {
bad_line("trailing whitespace", $_);

Now committing should work.

31 thoughts on “Git on Windows: “You have some suspicious patch lines””

  1. Unfortunately, once I added some files that contained CR-LF, git complains even on “pure UNIX” text files. I practically have to use –no-verify for *every* file now. Looks like Git sucks at having any DOS files in its repository — they seem to get in the way of other files somehow. Git won’t complain over the same files if I create a fresh repository and try to work with them the same way.

  2. Git from some time has core.autocrlf and crlf attribute, which should help in mixed UNIX (LF) and Windows (CR LF) environment

  3. Thanks a lot…it does work for me but I never edited the files in the windows based editors… I used the vi in the cygwin…

  4. I don’t understand why some one has to break their head to use a version control system. I have been playing with “git” for the last four days and I am still not able to checkin a file and checkout.

    I agree it might be faster working once we master all the tips & techniques of using “git”, but point is why should some one has to master a version control system rather than using it?

    I know many people might differ with me.

  5. @Martin — I use both git and bzr on a daily basis, and prefer bzr for new projects. git certainly has advantages — particularly on projects with very long histories, where bzr’s performance is presently less compelling — but while it’s head-and-shoulders above the last generation of SCMs (and certainly one of this generation’s best), I don’t think it’s completely settled that git is *the* SCM of this generation.

    Anyhow, re a better way to fix this issue…

    git-config –global core.whitespace fix

    …will trim unexpected endline whitespace, as opposed to just ignoring it. Same syntax for setting core.autocrlf to true if one wants to go that route.

  6. hmm, I actually end up seeing more instances of this error after using

    git-config core.autocrlf true
    git-config core.safecrlf true

  7. Well, yes, this could of course happen… But this time it really indicates that you have trailing whitespace (not just linebreaks).

    If you don’t care about the whitespace, it still is a valid solution to follow my initial advice and comment out the appropriate lines in the post-commit-hook.

  8. I find a better way is to have the pre-commit script chomp CRLF, rather than just ignoring all whitespace. To do this, just add this near the top of .git/hooks/pre-commit:

    $/ = “\r\n”; # chomp CRLF

    Also, core.autocrlf and core.safecrlf actually convert your CRLFs to LF in the repository. In a lot of cases this is undesirable.

  9. Note that my solution is for people that want and expect CRLFs in all of their files (i.e. using Visual Studio/.NET or whatever). If not, it is trivial to edit the pre-commit script to optionally remove any CRs before looking for trailing white space if expecting a mix of LF and CRLFs.

  10. Specifically, something like this should work:

    if (s/^\+//) {
    s/\r//g; # get rid of any carriage returns
    if (/\s$/) {
    bad_line(“trailing whitespace”, $_);

    Setting $/ globally might screw up something else – so this is probably the better option.

  11. thanks for your solution, I had this problem on mac os x leopard and oucommenting

    if (/\s$/) {
    bad_line(“trailing whitespace”, $_);

    in .git/hooks/pre-commit solved it

  12. My requirements are:

    o By default I want it to be possible and safe to have files
    with arbitrary line ending conventions in the same repository.
    In general, I want Git to not modify content (not change line endings).
    Put another way, it should just do what I tell it to do
    (that may not be what I meant, but that is another issue).

    o In order to be able to commit, the pre-commit hook needs to allow
    the allowed line-ending conventions. For me, this does it:
    if (/\s\r?\n?/) {
    bad_line(“trailing whitespace”, $_);

  13. Sorry, that should have been
    if (/[ \t]\r?\n?$/) {
    bad_line(”trailing whitespace”, $_);

    I don’t want to reject trailing whitespace other than space and tab.

  14. Thank you!
    The initial solution really works, but as I’m not a big specialist in web-development, let me ask a question: developing with Ruby on Rails – do I need to care about trailing whitespaces?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.