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.

Related Articles:

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.

  • http://chaliy.name Mike Chaliy

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

    • http://solutionizing.net/ Keith Dahlby

      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: http://grebulon.com/software/stripem.php
      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.

  • http://twitter.com/PortFwdPodcast Port Forward Podcast

    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 http://portforwardpodcast.com/

  • http://www.bikexprt.com/streetsmarts/usa/index.htm billdav

    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.

    • http://solutionizing.net/ Keith Dahlby

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

      • http://www.bikexprt.com/streetsmarts/usa/index.htm billdav

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

        • http://solutionizing.net/ Keith Dahlby

          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.

          • http://www.bikexprt.com/streetsmarts/usa/index.htm billdav

            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?

  • http://profiles.google.com/michel.memeteau michel memeteau

    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 https://help.github.com/articles/dealing-with-line-endings

    • http://solutionizing.net/ Keith Dahlby

      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:

        text

        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.