Git core.safecrlf在具有相同行尾的文件上的不同行为

我有与VS项目的Windows机器,并使用Visual Studio和从Cygwin环境包括Git的工具。 有时我会在编辑后的文件中得到不同的行结尾。 我想要简单的解决scheme来检查文件的行结束一致性之前,他们去回购。 Git的core.safecrlf是我想的正确的事情。 现在我有一个奇怪的行为:

文件AB具有以下参数:

 $file A A: HTML document, UTF-8 Unicode text, with CRLF line terminators $file B B: HTML document, UTF-8 Unicode (with BOM) text, with CRLF line terminators 

文件A已经在回购,文件B是新的。 请注意,两者都有CRLF行尾。 现在尝试把它们core.safecrlf一起, core.safecrlftrue

 $git add A # ok $git add B # fails fatal: CRLF would be replaced by LF in B. 

正确使用core.safecrlf ? 或者,也许我需要写钩来检查文件?

笔记:

  • 尝试不同的文件编码(有和没有BOM),没有区别。
  • 在Git中有相关的core.autocrlf特性,添加到标签(Stackoverflow没有core.safecrlf标签)
  • git版本1.8.5.rc1.17.g0ecd94d(在Cygwin下编译)

编辑#1:签出core.autocrlf – 这是input 。 更改为false ,现在我可以添加这两个文件。 为什么?

根据你以后编辑core.autocrlf = input是原来的设置。 使用此设置时, CRLF在签入到存储库时将转换为LF ,并在检出时保持这种状态。 这意味着像记事本这样的非Unix行结束的编辑器会弄乱文件的签出版本的外观。 这将是一个巨大的长线。

FWIW core.autocrlf = input是Unix系统的首选设置,使用默认的cygwin版本可能是这样设置的。 在Windows中,建议的设置是core.autocrlf = true ,这是msysgit推荐的

core.safecrlf = true如果检出文件将导致文件转换,如果记事本是编辑器,则会导致文件被更改并可能被损坏。 这就是文件B被中止的原因,因为它会在记事本之类的编辑器中混乱。 core.SAFEcrlfcore.AUTOcrlf之间的区别应该注意。 这是理解git line结尾的问题之一

core.autocrlf = false是不关心模式。 它将检查和检查文件完全一样,这就是为什么提交现在的工作。 这不是很聪明,不推荐使用,因为如果在Windows和Unix系统上编辑这些文件,以及如果另一个用户core.autocrlf设置不同并更改文件结尾,则会导致问题。

如果项目中的所有 Windows编辑器和其他文本文件处理工具都是Unix行结束,则我自己的首选是将core.autocrlf设置为在Windows上input ,否则将其设置为core.autocrlf = true对于core.autocrlf = input对于Unix。 在任何情况下,这种方法都超越了.gitattributes文件的优越方法。

.gitattributes文件方法根据文件名处理文件,并在所有用户环境中维护,因为它会像.gitignore一样签出到工作目录中。 应该将与项目相关的文件名和类型设置添加到.gitattributes 。 如果文件名在.gitattributes不匹配,则您的配置将回退到本地core.autocrlf和core.safecrlf设置。 在.gitattributes的顶部添加* text=auto会导致git对文件名进行最佳猜测,这些文件名与以后的.gitattributes设置不匹配。

这个网页, 注意你的线路的结束帮助我更好地理解这个问题。 你可以阅读更多关于这个问题的背景。

CR LF行结束选择不容易理解。 有两个地方的描述,它包括在Git-attributes和Git-config手册中。

最初有autocrlf设置,然后有更新的版本有一些潜在的不兼容性(即做你意想不到的事情)。

我倾向于设置eol = LF,这使得所有的文本文件被提交为LF行结束符(您可以设置哪些文件被视为文本的属性),然后添加safecrlf进行往返检查。