Home > development, software > Git on Windows: “You have some suspicious patch lines”

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.

  1. AMIGrAve
    December 1st, 2007 at 18:54 | #1

    This info saved my day ! Thanks !

  2. Anonymous
    December 4th, 2007 at 12:16 | #2


  3. December 13th, 2007 at 04:25 | #3

    THANK YOU!!!!!!

  4. Venkatesh Nandakumar
    December 16th, 2007 at 12:07 | #4

    Thank god for your blog post and Google!

  5. AdSR
    December 19th, 2007 at 10:52 | #5

    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.

  6. December 19th, 2007 at 12:21 | #6

    Hmm, strange, I cannot confirm this for me here, but maybe I have squelched the error message, I’ll have to check.

    Thanks for your comment!

  7. December 27th, 2007 at 14:48 | #7

    AdSR, You can use the dos2unix to clean up the files which contain the CR-LF.

  8. Jakub Narebski
    January 21st, 2008 at 18:22 | #8

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

  9. April 13th, 2008 at 20:55 | #9

    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…

  10. FP
    April 21st, 2008 at 21:44 | #10

    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.

  11. April 22nd, 2008 at 06:21 | #11

    I partly agree with you, git can be quite hard to learn. But once mastered, you’ll never want to use anything else.

  12. April 23rd, 2008 at 20:00 | #12

    Awesome, I was fighting with GIT over this issue this morning. You win!

  13. je
    June 2nd, 2008 at 16:33 | #13

    Thank you!!

  14. Charles Duffy
    June 9th, 2008 at 16:28 | #14

    @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.

  15. June 11th, 2008 at 22:53 | #15


    I tried your trick and it doesn’t work, however the original one did.

  16. June 12th, 2008 at 09:20 | #16

    @Russ: I think you should better use
    git-config core.autocrlf true
    git-config core.safecrlf true

    This is what really prevents the problem.

  17. Anonymous
    June 22nd, 2008 at 17:56 | #17

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

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

  18. June 22nd, 2008 at 20:42 | #18

    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.

  19. July 14th, 2008 at 17:54 | #19

    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.

  20. July 14th, 2008 at 18:06 | #20

    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.

  21. July 14th, 2008 at 18:17 | #21

    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.

  22. ben
    July 17th, 2008 at 22:48 | #22

    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

  23. July 30th, 2008 at 10:39 | #23

    I had this problem as well when I first started using Git, but today I ran into something else.

  24. Rainer Blome
    September 15th, 2008 at 11:14 | #24

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

  25. Rainer Blome
    September 15th, 2008 at 11:26 | #25

    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.

  26. yaakuro
    March 27th, 2009 at 20:39 | #26

    thx, saved my day too :).

  27. October 20th, 2009 at 17:30 | #27

    Thanks a lot. This was very useful.

  28. Blake
    December 1st, 2009 at 17:32 | #28

    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?

  29. December 1st, 2009 at 18:29 | #29

    I don’t think it is crucial, but the core.autocrlf and core.safecrlf always works and I see no reason not to use it.

  30. jake rikimaru
    December 18th, 2009 at 17:25 | #30

    Thx, saved me loads of frastration

  31. Bill
    July 21st, 2010 at 22:36 | #31

    Please someone answer this question!

  1. April 5th, 2009 at 23:26 | #1
  2. March 28th, 2010 at 10:35 | #2
  3. August 18th, 2010 at 07:18 | #3
  4. October 19th, 2012 at 11:18 | #4