我有与VS项目的Windows机器，并使用Visual Studio和从Cygwin环境包括Git的工具。 有时我会在编辑后的文件中得到不同的行结尾。 我想要简单的解决scheme来检查文件的行结束一致性之前，他们去回购。 Git的core.safecrlf是我想的正确的事情。 现在我有一个奇怪的行为：
文件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已经在回购，文件B是新的。 请注意，两者都有CRLF行尾。 现在尝试把它们core.safecrlf一起， core.safecrlf是true 。
$git add A # ok $git add B # fails fatal: CRLF would be replaced by LF in B.
正确使用core.safecrlf ？ 或者，也许我需要写钩来检查文件？
笔记：
core.autocrlf特性，添加到标签（Stackoverflow没有core.safecrlf标签） 编辑＃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.SAFEcrlf和core.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进行往返检查。