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

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 已在存储库中，文件 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版本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

设置不同并更改文件结尾，则会导致问题。

我自己的偏好是，如果项目上的

all

Windows 编辑器和其他文本文件处理工具支持 Unix 行结束符，则在 Windows 上将

core.autocrlf

设置为 input，否则将其设置为

core.autocrlf = true

（对于 Windows）和

core.autocrlf = input 

对于 Unix。无论如何，这种方法已经被

.gitattributes

文件的高级方法所过时了。

.gitattributes

文件方法根据文件名处理文件，并在所有用户环境中维护，因为它像

.gitignore

一样检出到工作目录中。与您的项目相关的尽可能多的文件名和类型的设置应添加到

.gitattributes

。如果文件名与

.gitattributes

中不匹配，您的配置将回退到本地 core.autocrlf 和 core.safecrlf 设置。在

*   text=auto

顶部添加

.gitattributes

将导致

git

对与后续

.gitattributes

设置不匹配的文件名进行最佳猜测。

这个网页，注意你的行尾帮助我更好地理解了这个问题。您可以阅读有关该问题的更多背景知识。

Answer 2

CR LF 行尾选择并不容易理解。有两个地方可以进行描述，Git 属性和 Git 配置手册中都有介绍。

最初有 autocrlf 设置，然后有较新的版本，它们有一些潜在的不兼容性（即按照您的指示做意想不到的事情）。

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

Answer 3

我们在 linux / macos / windows 混合环境中工作很多，唯一有效的选择是：git，请不要修改行结尾，不要管它们。所以

core.autocrlf = false

。