我有带有 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
,现在我可以添加这两个文件。为什么?
最佳答案
根据您后来的编辑,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帮助我更好地理解这个问题。您可以阅读有关该问题的更多背景信息。
关于windows - Git core.safecrlf 对具有相同行尾的文件的不同行为,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/19978063/