1

I've seen a couple of posts on here talking about how ^M appears in diff's. Indeed, if I go on GitHub, run git show or git diff ... I see the entire file is changed, and it is treated as a single line.

My colleague works on Mac, and I am on Windows, and I understand that the Windows line-endings are the problem, so you need to follow github's instructions and run

$git config --global core.autocrlf true

Which I did. Now, when I commit files using a text editor, I see

hint: Waiting for your editor to close the file... unix2dos: converting file full_path/.git/COMMIT_EDITMSG to DOS format...

They also say run:

$git add . -u
$git commit -m "Saving files before refreshing line endings"
$git add --renormalize .
$git commit -m "Normalize all the line endings"

But the problem is this does nothing. It just says my working tree is clean.

Now, if I run:

$git config --global core.autocrlf true

and then immediately add 2 new lines to one of my files, adding and committing this file still leaves me with the big jumbled mess and the changes being interpreted as happening to the entire file. I still see ^M everywhere.

I've seen this answer as well, and it says to run

# Remove everything from the index
$git rm --cached -r .

# Re-add all the deleted files to the index
# You should get lots of messages like: "warning: CRLF will be replaced by LF in <file>."
$git diff --cached --name-only -z | xargs -0 git add

# Commit
$git commit -m "Fix CRLF"

But the line starting with git diff just says "Nothing specified, nothing added." I tried writing:

$git diff --cached --name-only -z | xargs -0 git add .

But still, a git status showed there was no difference.

So then, I ran the next string of commits:

  1. First commit: delete test.txt
  2. Second commit: checkout the previous version of test.txt and commit it
  3. Add 2 lines of text to test.txt

Now, git show should show me the difference between test.txt and the version with 2 less lines: but there is still that ^M. This is despite the fact that it says

hint: Waiting for your editor to close the file... unix2dos: converting file full_path/.git/COMMIT_EDITMSG to DOS format...

So clearly, it is at least converting my edit message, but why are none of these solutions working for me? Why won't git actually convert my line endings?

Edit

I've now also tried: uninstalling Git, deleting the folder in my program files, and deleting .gitconfig at a global scale, then reinstalling with the option "checkout Windows style, commit Unix style line endings." But this did not work.

Manually going in and replacing the line endings with "\n" (through find and replace) has worked, and now git diff is cleanly displayed, but I'd like a way to ensure my projects never face this issue again, because noticing it required actually looking at the line endings which by default I do not show.

Note that adding *.txt eol=lf to .gitattributes in my repository and ensuring the filename is exactly .gitattributes with no extension works on a project by project basis.

Kraigolas
  • 5,121
  • 3
  • 12
  • 37
  • 1
    I recommend avoiding the `autocrlf` stuff in favor of the `*.txt eol=lf` style, but this should have worked, so I'm not sure what's gong on here. I will say, though, that the message `unix2dos: converting file full_path/.git/COMMIT_EDITMSG to DOS format...` is saying that you have your system configured to write your *log messages* with Windows-style CRLF line endings. Usually people work to do it the other way (use Linux-style line endings everywhere, including in log messages). – torek Mar 08 '21 at 23:07
  • @torek I would love to use Linux-style endings everywhere. I'm not sure why Windows doesn't just default to them considering it can interpret them just fine. – Kraigolas Mar 08 '21 at 23:10
  • 1
    [Hysterical raisins](http://www.catb.org/jargon/html/H/hysterical-reasons.html) – torek Mar 08 '21 at 23:11
  • @torek I used someone's cmd code which ran something like `echo *.txt eol=lf > .gitattributes` and despite opening it to ensure it contained exactly *.txt eol=lf, it did not work. However, adding my own .gitattributes just now has magically solved the problem. I still consider this problem unresolved because `git config --global core.autocrlf true` still does absolutely nothing, but for any future readers, adding `.gitattributes` to the repo works. – Kraigolas Mar 08 '21 at 23:51
  • Hm: are you using bash, or powershell, or some other shell? I understand (n-th hand as I don't actually use Windows) that powershell tends to write UTF-16-LE "text" files, which won't work with Git, which only understands ASCII and UTF-8. That might explain the `.gitattributes` glitch. Still not sure why the autocrlf method didn't work but I dislike it anyway as it is too imprecise and requires each user to set their config. – torek Mar 09 '21 at 06:32
  • For that command I used `cmd`. But yes I agree the repo should enforce line endings not each user. – Kraigolas Mar 09 '21 at 18:26

0 Answers0