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

enter image description here

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

  • 1
    Have you done C-u C-x = on some characters of the diff to confirm your hunch? The only difference between dos and unix encodings is the CR vs CR/LF issue AFAIK.
    – NickD
    Jul 16 at 17:02
  • I did not, but will try that next time the issue comes up. (Already bit the bullet and made the commit) Jul 16 at 18:33
  • My general suggestion is to stick to the native file endings of your OS — lf on *nix, crlf on windows. And to configure gitattributes to ensure this. Cleaning out messed file endings when the repo already exists is a bigger headache. I recommend you check my suggestions work on a new clean repo first
    – Rusi
    Jul 31 at 7:45

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.

  • 1
    Nice - poarticularly the last sentence :-)
    – NickD
    Jul 17 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.