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.
C-u C-x =
on some characters of the diff to confirm your hunch? The only difference betweendos
andunix
encodings is theCR
vsCR/LF
issue AFAIK.