Git core.safecrlf对具有相同行结尾的文件的不同行为

Question

我有带VS项目的Windows机器,我使用Visual Studio和Cygwin环境中的工具,包括Git.有时我在编辑后会在文件中得到不同的行结尾.我想要简单的解决方案来检查文件的行结束一致性,然后再去回购.core.safecrlf我认为Git 是正确的.现在我有一个奇怪的行为:

文件A和B以下参数:

$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已经在repo中,文件B是新的.注意,两者都有CRLF行结尾.现在尝试上演他们,core.safecrlf是true.

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

我core.safecrlf正确使用？或者我可能需要编写钩子来检查文件？

笔记:

• 试过不同的文件编码(有和没有BOM),没有区别.
• core.autocrlfGit中有相关功能,将其添加到标签中(Stackoverflow没有标签core.safecrlf)
• git版本1.8.5.rc1.17.g0ecd94d(从Cygwin下的源代码编译)

编辑#1:签出core.autocrlf- 它是input.改为false,现在我可以添加两个文件.为什么？

Answer 1

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

FWIW core.autocrlf = input是Unix系统上的首选设置,使用默认cygwin构建可能就是这样设置的.在Windows的推荐设置是core.autocrlf = true这是什么msysgit建议

core.safecrlf = true如果检出文件将导致文件被更改且可能已损坏,则会中止文件的转换,如果记事本是编辑器,则会出现这种情况.这就是为什么文件B被中止的原因,因为它会在记事本之类的编辑器中搞砸.应该注意core.SAFEcrlf和之间的区别core.AUTOcrlf.这是eyes glazing over理解git行结尾的问题之一

core.autocrlf = false是不关心模式.它将检查并检查完全相同的文件,这就是提交现在正常工作的原因.这不是很聪明,不推荐使用,因为如果在Windows和Unix系统上编辑文件,并且如果其他用户core.autocrlf设置不同并更改文件结尾,则会导致问题.

我自己的选择是设置core.autocrlf到inputWindows上,如果所有 Windows的编辑器和其他文本文件处理工具上的项目有结束意识到Unix行,否则将其设置为core.autocrlf = true适用于Windows和core.autocrlf = input为Unix.无论如何,这种方法已经过时了.gitattributes文件的优越方法.

该.gitattributes文件的方法处理基于文件名的文件,并保持在所有用户环境中,因为它被检出到喜欢的工作目录.gitignore.应添加与项目相关的任意数量的文件名和类型的设置.gitattributes.如果文件名不匹配,您的配置将回退到本地core.autocrlf和core.safecrlf设置.gitattributes.* text=auto在顶部添加.gitattributes将导致git对文件名进行最佳猜测,这些文件名与后面的.gitattributes设置不匹配.

这个网页,Mind the End of Your Line帮助我更好地理解了这个问题.您可能会阅读有关该问题的更多背景信息.