Recently, when doing a "git diff" on Windows, I noticed that all the lines I had edited were displaying a ^M character at the end of the line. I understand line endings are a common problem in git with cross-platform projects, but my installation is properly configured with core.autocrlf set to true, the recommended setting for Windows.
So I figured that the editor must be adding CRLF line endings to the new lines, and git diff was simply confused, not realizing that it was supposed to normalize these line endings into LF upon commit, and thus incorrectly displaying the ^M character.
So to help it out, I went into my editor and forced a conversion to Unix-style line endings.
Then, when I typed "git diff" it no longer showed the ^M character, but it showed that every single line of the file had changed (even lines that were identical).
So I tried forcing a conversion back to Windows-style line endings, and now "git diff" showed a ^M after every line, and showed every line as changed.
That was no good, so I went back to the Unix-style line endings, and tried a few more things, like explicitly adding a .gitattributes text=auto line, removing the index and "git reset". Didn't make a bit of difference.
I can't figure out why both Windows-style line endings and Unix-style line endings are causing git to think that every line of the file is edited. It seems like one of those two scenarios should work.
With the file set to Unix-style line endings, "git diff -w" shows exactly the changed lines, nothing more, nothing less. Essentially, I want to commit that to git, so I can get back to some sort of reasonable state, and not have the git history show falsely that I edited every line of the file. How do I do that?
