Git detects changed files that are actually byte-identical

Question

I have an issue with git (through tortoise git) that shows some files of my project as modified, but they are actually not modified. I have double-checked that by making a fresh clone of the repository, and, without touching it, I already have git detect "modified" files in the newly created working copy. This is annoying because some operations are blocked (because that would override my "modified" files), but I can't revert them, deleting+revert doesn't work either. Committing the "changes" works but it's not an ideal solution.

I'm on Windows, using TortoiseGit 1.8.16.0 and Git 2.6.4. Using git status directly also shows the same files are "modified".

This seems to happen only in a directory of my project that used to be a submodule, but I'm now using git subtree. So at some time, I removed the submodule completely (or so I think), and created a subtree.

Did anyone have the same issue? How could I fix it once and for all? (even after committing the "changes", some time later, sometimes weeks later, I will have other files, or sometimes the same files, starting to show the same weird issue).

Here is the result of diff on one of those files: git diff app.config

diff --git a/Ozytis.Common/Web/app.config b/Ozytis.Common/Web/app.config
index 3686aab..f559fe7 100644
--- a/Ozytis.Common/Web/app.config
+++ b/Ozytis.Common/Web/app.config
@@ -1,25 +1,25 @@
-<U+FEFF><?xml version="1.0" encoding="utf-8"?>
-<configuration>
-  <configSections>
-    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
-    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=ne
utral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
-  </configSections>
-  <runtime>
-    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
-      <dependentAssembly>
-        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
-        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
-      </dependentAssembly>
-    </assemblyBinding>
-  </runtime>
-  <entityFramework>
-    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
-      <parameters>
-        <parameter value="v11.0" />
-      </parameters>
-    </defaultConnectionFactory>
-    <providers>
-      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
-    </providers>
-  </entityFramework>
+<U+FEFF><?xml version="1.0" encoding="utf-8"?>
+<configuration>
+  <configSections>
+    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468 -->
+    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=ne
utral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
+  </configSections>
+  <runtime>
+    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
+      <dependentAssembly>
+        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
+        <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
+      </dependentAssembly>
+    </assemblyBinding>
+  </runtime>
+  <entityFramework>
+    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework">
+      <parameters>
+        <parameter value="v11.0" />
+      </parameters>
+    </defaultConnectionFactory>
+    <providers>
+      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />
+    </providers>
+  </entityFramework>
 </configuration>
\ No newline at end of file

For this file, the diff shows all lines are modified. However, I checked with an hexadecimal editor with previous and current version of the file, line feeds are the same, in fact every single byte is the same.

Also, some files show only a few lines are different (but again, they are not). Even though the whole file has consistent line feeds.

Answer 1

It seems indeed this is a line ending issue (thanks to user3159253 and HBHB for their comments about that).

Looks like a git bug though, because why does it report files are different, but at the same time when you get them on your machine it changes line endings so that you can't see where is the difference? I believe it should not show line ending differences (not with git status and not with git diff) if it is configured to change them anyway.

Also, I already tried changing core.autocrlf before asking my question, but it turns out my project contains a .gitattributes, and this was the real issue. The file started with * text and then a few file formats are changed to binary, and this takes precedence over core.autocrlf. Since everyone is working on Windows for this project, I changed it to * binary (see update below), at least now things are clear. That made git detect some more files as changed (again, git is not consistent about that?), but this time I actually see the line ending differences. I committed them, and I hope this is the end of the story.

UPDATE:

Using * binary in .gitattributes doesn't work either because now git can't merge text files since he thinks they are binary. The correct version (if you want to prevent git from changing line endings, but still correctly merge text files) is * -text:

Unsetting the text attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout.

http://git-scm.com/docs/gitattributes

This solution may not be ideal, because after refreshing your working copy, all your files will have unix-style line endings (because that's what was stored by git I suppose). So you have to convert all your files back to windows line endings (dos2unix helps) and make a big commit that will be a pain for future merging (if any).