Question

我有带VS项目的Windows机器，我使用Visual Studio和Cygwin环境中的工具，包括Git。有时我在编辑后会在文件中得到不同的行结尾。我想要简单的解决方案来检查文件的行结束一致性，然后再去回购。我认为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已经在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），没有区别。
Git中有相关的core.autocrlf功能，将其添加到代码中（Stackoverflow没有core.safecrlf的标记）
git version 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设置不同并更改文件结尾，则会导致问题。

我自己的偏好是在Windows上将core.autocrlf设置为input如果全部项目中的Windows编辑器和其他文本文件处理工具都知道Unix行结尾，否则对于Windows，将其设置为core.autocrlf = true，对于Unix，将其设置为core.autocrlf = input。无论如何，这种方法已经过时了.gitattributes文件的优越方法。

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

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

Answer 2

CR LF线结束选择并不容易理解。有两个描述的地方，它在Git-attributes和Git-config手册中都有介绍。

最初有autocrlf设置，然后有较新的版本有一些潜在的不兼容性（即你做的意外事情）。

我倾向于设置eol = LF，这使得所有文本文件都被提交为LF行结尾（您可以设置关于哪些文件被视为文本的属性），然后添加safecrlf进行往返检查。

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

2 个答案: