Git检测实际字节相同的已更改文件

时间:2015-12-17 10:20:43

标签: windows git git-submodules git-subtree

我有一个git(通过togise git)的问题,它显示了我的项目的一些文件被修改,但它们实际上没有被修改。我通过对存储库进行新的克隆来仔细检查,并且在没有触及它的情况下,我已经有了git detect" modified"新创建的工作副本中的文件。这很烦人,因为某些操作被阻止(因为这会覆盖我的"修改过的"文件),但我无法恢复它们,删除+恢复也无法正常工作。致力于改变"有效,但它不是一个理想的解决方案。

我在Windows上使用TortoiseGit 1.8.16.0和Git 2.6.4。直接使用git status也会显示相同的文件被修改"。

这似乎只发生在我曾经是子模块的项目目录中,但我现在正在使用git子树。所以在某个时候,我完全删除了子模块(或者我认为),并创建了一个子树。

有没有人有同样的问题?我怎么能一劳永逸地解决这个问题? (即使在提交"更改",一段时间后,有时几周后,我将有其他文件,或者有时相同的文件,开始显示相同的奇怪问题)。

以下是其中一个文件的差异结果: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

对于此文件,diff显示所有行都被修改。但是,我使用十六进制编辑器检查了文件的先前版本和当前版本,换行符是相同的,实际上每个字节都是相同的。

另外,有些文件显示只有几行不同(但同样,它们不是)。即使整个文件都有一致的换行符。

1 个答案:

答案 0 :(得分:3)

这似乎确实是一个行结束问题(感谢user3159253和HBHB对此的评论)。

虽然看起来像一个git bug,因为它为什么报告文件不同,但同时当你在机器上获取它时它会改变行结尾,这样你就看不出差异在哪里?我认为它不应该显示行结尾差异(不是git status而不是git diff),如果它被配置为无论如何都要改变它们。

另外,在问我的问题之前,我已经尝试更改core.autocrlf,但事实证明我的项目包含.gitattributes,这是真正的问题。该文件以* text开头,然后一些文件格式更改为二进制,这优先于core.autocrlf。由于每个人都在Windows上为这个项目工作,我把它改为* binary (见下面的更新),至少现在情况很清楚。这使得git检测到更多的文件被更改(再次,git与此不一致?),但这次我实际上看到了行结束差异。我承诺了,我希望这是故事的结局。

<强>更新

在.gitattributes中使用* binary并不起作用,因为现在git无法合并文本文件,因为他认为它们是二进制文件。正确的版本(如果您想阻止git更改行结尾,但仍然正确合并文本文件)是* -text

  

在路径上取消设置text属性会告诉Git在签入或结帐时不要尝试任何行尾转换。

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

这个解决方案可能不太理想,因为在刷新工作副本之后,所有文件都会有unix样式的行结尾(因为我认为这是git存储的内容)。因此,您必须将所有文件转换回Windows行结尾(dos2unix帮助)并进行大量提交,这将对将来的合并(如果有的话)带来痛苦。