Windows Git Tip: Hide ^M (Carriage Return) in Diff

A common point of confusion when getting started with Git on Windows is line endings, with Windows still using CR+LF while every other modern OS uses LF only. Git provides three ways to deal with this discrepancy, as described in the msysGit installer:

  1. Checkout Windows-style, commit Unix-style (core.autocrlf = true)
  2. Checkout as-is, commit Unix-style (core.autocrlf = input)
  3. Checkout as-is, commit as-is (core.autocrlf = false)

The first option is the default, which I find rather unfortunate—I don’t consider line ending manipulation to be the responsibility of my VCS. Instead, I prefer to keep core.autocrlf set to false and let my text editors deal with line endings. (If you like having core.autocrlf set to true or input, I’d love to hear why.)

One downside of turning off autocrlf is that the output of git diff highlights CR characters (indicated by ^M) as whitespace errors. To turn off this “error”, you can use the core.whitespace setting:

git config --global core.whitespace cr-at-eol

If your core.whitespace is already set, you should add cr-at-eol to the end of the comma-delimited list instead.

About Keith Dahlby

I'm a .NET developer, Git enthusiast and language geek from Cedar Rapids, IA. I work as a software guru at J&P Cycles and studied Human-Computer Interaction at Iowa State University.
This entry was posted in git, msysgit. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • martin t.

    I prefer core.autocrlf = input. This the way the line endings are always LF on the remote bare repository.

  • Seems, most ppl uses first option. And as for me this is responsibility of VCS client to adopt to host OS. So I am from thouse ppl who use first option.

    P.S. Do you know how to configure VS to use unix line endings?
    P.P.S. “every other modern OS ” is still less then 10%?

    • 10% overall, perhaps, but much higher among developers and higher still among those using Git.

      I’ve never tried to set VS to use unix line endings, but I also view VS projects as single-platform. Maybe if I did work on Mono I would change my tune…we’ll see. For cross-platform stuff (JS projects, for example), I’m more likely to use another editor anyway.

    • acolin

      > P.S. Do you know how to configure VS to use unix line endings?
      Strip’em addin for VS helps:
      However, when VS writes .csproj and .sln files (and probably others), the hook used by this plugin seems to not get called, so I just dos2unix -U on those files manually.

  • Yuriy

    Python and some other la huger require correct line endings. If you need to run the same scripts on different platforms you have nochoice other than checkout with latgrm style line ends and vmit in unix syyle.

  • Don’t forget that if your on Ubuntu Linux you can just change the line endings yourself and verify that your code still compiles.

    to remove ^M (extra CR)  run this command:
    fromdos file.txt

    to add CR back
    todos file.txt

    Ubunu todos/fromdos are the commands, however other distros use dos2unix, unix2dos

    -Ben of

  • I prefer “input” because it keeps the repository Unix style, as it should be.

    All IDE’s that I am aware of as well as most text editors other than notepad work just fine without carriage returns at the end of lines.  I don’t want developers on my project if they’re going to use notepad to edit files.

    •  ”as it should be” strikes me as odd given that Git is the only VCS that touches line endings. That said, I’m settling on “input” for cross-platform projects and “false” for Windows-only projects.

      • Apparently you aren’t familiar with SVN or Perforce.  Mercurial has an extension available.

        • I guess I used Subversion for years without knowing it was doing EOL conversion. That’s how it should be. In Git it’s front and center for users on Windows, to its detriment.

          • I don’t use git on Windows.  I installed it on my Windows box a while back just in case I ever want to use it.

            In Linux, git defaults to autocrlf = false.  I’m a little surprised that Windows has a different default there.  It may have something to do with whomever built the package.  I don’t have enough motivation to track it down.  Which package are you using?

  • Well we use 
    core.autocrlf = true just because we have people developing on Windows with different Editors

  • Tomasz Wesołowski

    I prefer to stay with core.autocrlf = false and rely on the newer mechanism (.gitattributes) to make sure the repo remains clean. See

    • Do you mean autocrlf = true? That’s what I typically see on Windows with repos that have a .gitattributes. I haven’t bothered to convert old repos (created before .gitattributes was a thing), but this is how I handle new ones.

      • Tomasz Wesołowski

        I don’t know how autocrlf is relevant with .gitattributes with respect to what gets committed. Quoting the help page:


        This setting tells git to always normalize the files specified. When committed they are stored with LF, on checkout they are converted to the OS’s native line endings.

        This is nice because your working copy can have any endings, and the repo will remain clean.