Git открива променени файлове, които всъщност са идентични по байт

Имам проблем с git (през git на костенурка), който показва някои файлове от моя проект като модифицирани, но те всъщност не са модифицирани. Проверих това, като направих нов клонинг на хранилището и, без да го пипам, вече имам git detect "модифицирани" файлове в новосъздаденото работно копие. Това е досадно, защото някои операции са блокирани (защото това би отменило моите „модифицирани“ файлове), но не мога да ги върна, изтриването+връщането също не работи. Комитирането на „промените“ работи, но не е идеалното решение.

Аз съм на Windows, използвам TortoiseGit 1.8.16.0 и Git 2.6.4. Използването на git status директно също показва, че същите файлове са "модифицирани".

Това изглежда се случва само в директория на моя проект, която преди беше подмодул, но сега използвам git subtree. Така че по някое време премахнах изцяло подмодула (или поне така си мисля) и създадох поддърво.

Някой имал ли е същия проблем? Как мога да го поправя веднъж завинаги? (дори след извършване на „промените“, известно време по-късно, понякога седмици по-късно, ще имам други файлове или понякога същите файлове, които започват да показват същия странен проблем).

Ето резултата от diff на един от тези файлове: 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

За този файл разликата показва, че всички редове са променени. Въпреки това проверих с шестнадесетичен редактор с предишна и текуща версия на файла, линиите на ред са еднакви, всъщност всеки един байт е един и същ.

Освен това някои файлове показват, че само няколко реда са различни (но отново не са). Въпреки че целият файл има последователни емисии на редове.


git windows git-submodules git-subtree
person youen    schedule 17.12.2015    source източник
comment
Променени ли са разрешенията за файлове?   -  person Claudio    schedule 17.12.2015
comment
Какво показва git diff?   -  person choroba    schedule 17.12.2015
comment
@choroba 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> [snip] - </entityFramework> +<U+FEFF><?xml version="1.0" encoding="utf-8"?> +<configuration> + <configSections> [snip] + </entityFramework> </configuration> \ No newline at end of file PS: няма начин да се запазят редовете в коментарите?   -  person youen    schedule 17.12.2015
comment
Не можете да запазите LF в коментар, но можете да добавите git diff изход към съдържанието на въпроса   -  person Zdeslav Vojkovic    schedule 17.12.2015
comment
Предполагам, че git diff --ignore-space-at-eol ще обясни проблема, ‹CR›‹LF› срещу ‹LF›   -  person user3159253    schedule 17.12.2015
comment
@user3159253 вашата команда не дава резултат. Не знам какво да мисля за това. Проверих файловете си с шестнадесетичен редактор: те имат абсолютно същите канали на редове в предишна/следваща версия (0x0d 0x0a). Освен това не съм пипал някои от файловете няколко месеца, защо изведнъж се показват модифицирани? И защо след пресен клонинг?   -  person youen    schedule 17.12.2015
comment
@Claudio Току-що клонирах хранилището, не промених разрешенията за файлове или каквото и да било. Изобщо не промених разрешенията за файлове през целия живот на проекта, доколкото си спомням (между другото съм на Windows)   -  person youen    schedule 17.12.2015
comment
@youen, ако следвате този отговор , файлът изчезва ли от git status? Ако е така, предполагам, че има грешка с вашия шестнадесетичен редактор или с вашата git инсталация   -  person houtanb    schedule 17.12.2015
comment
@youen това наистина е проблемът с края на реда. Вижте този документ и след това опитайте различни варианти на настройката core.autocrlf. Може също така да се наложи да коригирате принудително проблема с края на реда в нов комит.   -  person user3159253    schedule 17.12.2015

Отговори (1)


arrow_upward
3
arrow_downward

Изглежда наистина това е проблем с края на реда (благодарение на user3159253 и HBHB за техните коментари за това).

Все пак изглежда като грешка в git, защото защо докладва, че файловете са различни, но в същото време, когато ги получите на вашата машина, той променя краищата на редовете, така че да не можете да видите къде е разликата? Вярвам, че не трябва да показва разлики в края на реда (не с git status и не с git diff), ако е конфигуриран да ги променя така или иначе.

Освен това вече опитах да променя core.autocrlf, преди да задам въпроса си, но се оказа, че моят проект съдържа .gitattributes и това е истинският проблем. Файлът започва с * text и след това няколко файлови формата се променят на двоични и това има предимство пред core.autocrlf. Тъй като всички работят върху Windows за този проект, промених го на * binary (вижте актуализацията по-долу), сега поне нещата са ясни. Това накара git да открие още някои файлове като променени (отново, git не е последователен за това?), но този път всъщност виждам разлики в края на реда. Аз ги ангажирах и се надявам това да е краят на историята.

АКТУАЛИЗАЦИЯ:

Използването на * binary в .gitattributes също не работи, защото сега git не може да обедини текстови файлове, тъй като смята, че са двоични. Правилната версия (ако искате да попречите на git да променя краищата на редове, но все пак правилно да обединявате текстови файлове) е * -text:

Отмяната на текстовия атрибут на пътя казва на Git да не прави опити за преобразуване в края на реда при чекиране или плащане.

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

Това решение може да не е идеално, защото след опресняване на вашето работно копие, всичките ви файлове ще имат окончания на редове в unix стил (защото това е, което се съхранява от git, предполагам). Така че трябва да преобразувате всичките си файлове обратно в краища на редове на Windows (dos2unix помага) и да направите голям ангажимент, който ще бъде проблем за бъдещо сливане (ако има такова).

person youen    schedule 17.12.2015