Ignore file encoding in diff

Question

My magit diff is full of "differences" where there is no visually discernible change.

I've adjusted every Magit Diff Option. Configuring magit to ignore line endings, tabs, whitespace, and indentation doesn't silence the noise, so I conclude those aren't the culprit.

My init forces UTF-8:

(prefer-coding-system 'utf-8)
(set-default-coding-systems 'utf-8)
(set-terminal-coding-system 'utf-8)
(set-keyboard-coding-system 'utf-8)
(set-language-environment "utf-8")

I should be good, right? Apparently not. The encoding of init.el on my Windows machine is UTF-8-dos whereas on my GNU machine is UTF-8-unix. I conclude that this is the source of the noise.

I understand the problem to be with how each Git repo/clone is configured per system. It looks like the filter option of .gitattributes might resolve future problems. However, that looks to only work for checkouts; I don't think it does anything for the immediate problem of "I want to commit some changes right now".

It's probably silly to ask how to "ignore encodings", but I'm not an expert in how encodings function. Frankly, I don't care beyond understanding, "how can I silence the noise so that I can see the meaningful differences and just make the commit?"

Answer 1

Magit doesn’t generate these diffs. Instead Git creates the diffs and Magit only presents them. It looks like the diff you are seeing is happening because the line endings have changed, or possibly the other whitespace in the line has changed (tabs to spaces, for example).

You might be able to change how the diffs are presented (for example by turning on whitespace mode and configuring it to use visibly distinct glyphs for spaces and tabs, but there’s little that you can do about the line–ending problem. The diff format doesn’t even include the original line endings from the file; all the line endings are replaced with whatever Git thinks is correct for your platform.

There are two avenues you should explore. The first is to configure git to always checkout files using a consistent choice of line–ending character on all platforms. For example, you could configure it to always use LF or always use CRLF, whichever you prefer. You may have configured Emacs to prefer one line ending over the other, in which case changing the git config to match that preference would simplify the problem. Consult the Git documentation about the .gitattributes file for more information about how to do this.

The other alternative is to leave the Git configuration alone, and reconfigure Emacs. Git’s default behavior is to convert all line endings in text files to the default line–ending character for the current platform. So if you commit a file with LF as the line–ending character and then check it out on Windows, Git will write the file to disk with CRLF characters in their place. There are a number of ways to configure Emacs, so I recommend reading chapter 22.6 Recognizing Coding Systems in the Emacs manual (also available inside Emacs type C-h i to open the Info viewer).

Since the default Emacs behavior is to mimic the line endings already in the file, it may be the case that the file already had mixed line–ending characters and Emacs’ guessing is making the problem worse. If that is the case, I recommend making the file (or files) consistent before continuing. Go to your Linux computer and run dos2unix on all affected files, then commit any changes that result. (There are ways to do that same cleanup in Emacs, of course, but dos2unix is easier. Naturally you are unlikely to have it installed on your Windows machine.)

Of course this is all a lot more complex than it really needs to be. Honestly it’s a wonder that our computers even work.