17

I'm on Ubuntu 14.04. I'm editing files with Vim. Suddenly I started to notice that the changes that I make which I see with git diff filename contain ^M at the end of every line that I've inserted or changed. So after I run git add to the filename I see with git diff --staged that every line has ^M at the end and thus it's like if I made a change to the whole file even if I changed only one line. Please help me to understand what's going on here.

valk
  • 9,363
  • 12
  • 59
  • 79
  • you have a misconfigured line ending handling. There are a lot of topics on the site about this - `core.safecrlf` and `core.autocrlf` are the settings you should fix. Note that after fixing you might need to recreate your local checkout. – eis Jan 21 '15 at 21:04
  • 1
    Also, check out [this](https://help.github.com/articles/dealing-with-line-endings/). – eis Jan 21 '15 at 21:06
  • 1
    @eis thanks for suggestion, but Blake's answer actually worked – valk Jan 21 '15 at 21:15
  • yes, that's one way of resolving it as well. There are others, too, such as using .gitattributes for this. Each have their own characteristics and drawbacks. – eis Jan 22 '15 at 05:44

3 Answers3

13

Are your files being checked in from a Windows computer at any point? Windows adds CR+LF to line endings, while other OS's use LF only. If you've set core.autocrlf to false then git diff will highlight CR characters as ^M. To turn this off, you can alter the core.whitespace setting:

git config --global core.whitespace cr-at-eol
Blake Frederick
  • 1,510
  • 20
  • 31
  • 1
    It was edited probably on Windows before! It's routes.rb. Does that configuration completely ignores ^M or it actually doesn't insert them when staging, i.e. git-adding? – valk Jan 21 '15 at 21:17
  • 2
    It causes ^M just not to be displayed but it exists in files anyway. – Abdollah Dec 26 '20 at 08:07
  • 2
    @Abdollah gets +1 there. The ^M are still there. For me, this fix is worse than the disease. I have ^M causing merge conflicts, but they are now invisible to me. Blech. – pauljohn32 Aug 13 '21 at 14:56
  • Obrigado! Resolveu pra mim. – Marcello Infoweb Mar 16 '22 at 11:27
9

This solved this problem for me, I quote from following source: core.autocrlf explained

Hope this helps someone!

core.autocrlf

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true
dapc
  • 304
  • 3
  • 7
  • This solved the issue for me since I code on windows but deploy on linux. I prefer not changing the content rather than ignoring updates because the changes are expected. – Oron May 31 '23 at 22:48
6

I faced a similar problem when I copied my whole project directly from Windows to Linux. Regarding this document, I ran the following command on my Linux Terminal and the problem was resolved:

$ git config --global core.autocrlf input
Abdollah
  • 4,579
  • 3
  • 29
  • 49