16

我有带有 VS 项目的 Windows 机器，我使用 Visual Studio 和 Cygwin 环境中的工具，包括 Git。有时我在编辑后会在文件中得到不同的行尾。我想要一个简单的解决方案来检查文件的行尾一致性，然后再去回购。core.safecrlf我认为Git是正确的。现在我有一个奇怪的行为：

文件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，现在我可以添加两个文件。为什么？

4

2 回答 2

44

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

FWIWcore.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 编辑器和其他文本文件处理工具都支持 Unix 行尾，我自己的偏好是在 Windows上设置，否则core.autocrlf为Windows 和Unix 设置为。无论如何，这种方法已被文件的高级方法过时了。inputcore.autocrlf = truecore.autocrlf = input.gitattributes

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

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

于 2014-01-10T14:22:28.387 回答
3

CR LF 行尾选择并不容易理解。Git-attributes 和 Git-config 手册中有两个地方的描述。

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

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

于 2013-11-14T18:07:14.677 回答