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

Question

我有带有 VS 项目的 Windows 机器，我同时使用 Visual Studio 和来自 Cygwin 环境的工具，包括 Git。有时我在编辑后会在文件中得到不同的行尾。我想要简单的解决方案来检查文件的行尾一致性，然后再转到 repo 协议(protocol)。我认为 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？或者我可能需要编写钩子(Hook)来检查文件？

注意事项:

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

编辑 #1: checkout core.autocrlf - 它是 input。更改为 false，现在我可以添加这两个文件。为什么？

Answer 1

根据您后来的编辑，core.autocrlf = input 是原始设置。使用此设置，CRLF 在 checkin 存储库时转换为 LF，并在 checkout 时保持这种状态。这意味着像记事本这样的非 Unix 行尾识别编辑器会弄乱文件 checkout 版本的外观。这将是一条巨大的长线。

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

core.safecrlf = true 如果 checkout 文件会导致文件发生更改并可能损坏(如果记事本是编辑器，就会出现这种情况)，则中止文件的转换。这就是文件 B 被中止的原因，因为它在记事本等编辑器中会被弄乱。 core.SAFEcrlf 和 core.AUTOcrlf 的区别需要注意。这是理解 git 行尾的目光呆滞问题之一

core.autocrlf = false 是无关模式。它将按原样 checkin 和 checkout 文件，这就是提交现在起作用的原因。这不是很聪明，也不推荐这样做，因为如果文件在 Windows 和 Unix 系统上都被编辑，并且如果另一个用户 core.autocrlf 设置不同并更改文件结尾，它会导致问题。

我自己的偏好是在 Windows 上将 core.autocrlf 设置为 input 如果 所有项目是 Unix 行结束感知的，否则将其设置为 Windows 的 core.autocrlf = true 和 Unix 的 core.autocrlf = input。在任何情况下，这种方法都被 .gitattributes 文件的高级方法淘汰了。

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

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