Git core.safecrlf对具有相同行结尾的文件的不同行为 [英] Git core.safecrlf different behavior on files with same line endings

问题描述

我有Windows机器与VS项目，我使用Visual Studio和工具从Cygwin环境包括Git。有时我在编辑后得到不同的行尾。我想要简单的解决方案检查文件的行结束一致性之前，他们去repo。 Git的 core.safecrlf 是我想的正确的事情。
现在我有一个奇怪的行为：

I have Windows machine with VS project and I use both Visual Studio and tools from Cygwin environment including Git. Sometimes I get different line endings in files after editing. I want simple solution to check files' line ending consistency before they go to the repo. Git's core.safecrlf is the right thing I suppose. Now I have a strange behavior:

文件 A 和 / code>使用以下参数：

Files A and B with following parameters:

$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 。

File A is already in repo, file B is new one. Note, both have CRLF line endings. Now try to stage them, core.safecrlf is 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）

• tried with different file encodings (with and without BOM), no difference.
• there's related core.autocrlf feature in Git, added it to tags (Stackoverflow has no tag for core.safecrlf)
• git version 1.8.5.rc1.17.g0ecd94d (compiled from sources under Cygwin)

编辑＃1：签出 core.autocrlf 它是输入。更改为 false ，现在我可以添加这两个文件。为什么？

EDIT #1: checked out core.autocrlf - it was input. Changed to false, now I can add both files. Why?

推荐答案

根据您以后的编辑 core.autocrlf = input 是原来的设置。使用此设置 c>当检入到存储库中时， CRLF 会转换为 LF 强>检出时。这意味着一个非Unix行结束感知编辑器，如记事本会搞砸文件的签出版本的外观。

According to your later edit core.autocrlf = input was the original setting. With this setting CRLF is converted to LF when checked in to the repository and is kept that way when checked out. This means a non Unix line endings aware editor like Notepad would mess up the appearance of a checked out version of the file. It would be one giant long line.

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

FWIW core.autocrlf = input is the preferred setting on Unix systems and using the default cygwin build probably set it that way. In Windows the recommended settings is core.autocrlf = true which is what msysgit recommends

core.safecrlf = true 中止文件的转换，如果检出该文件将导致更改和可能损坏的文件如果记事本是编辑。这就是为什么文件B被中止，因为它会在像记事本这样的编辑器中搞乱。应该注意 core.SAFEcrlf 和 core.AUTOcrlf 之间的区别。它是眼睛在理解 git 行结尾

core.safecrlf = true aborts the conversion of a file if checking out the file will result in a changed and possibly damaged file which would be the case if Notepad was the editor. This is why file B was aborted because it would be messed up in an editor like Notepad. The difference between core.SAFEcrlf and core.AUTOcrlf should be noted. It is one of the eyes glazing over issues in understanding git line endings

core.autocrlf = false 是无关模式。它将检入和检查文件，就像它们是，这就是为什么提交现在工作。这不是很聪明，不推荐，因为它会导致问题，如果文件在Windows和Unix系统上编辑，并且如果另一个用户 core.autocrlf 设置不同，并更改文件结束。

core.autocrlf = false is don't care mode. It will check in and check out the files exactly as they are, which is why the commits now work. This is not very smart and is not recommended because it causes problems if the files are edited on both Windows and Unix systems and also if another users core.autocrlf settings differ and change the file endings.

我自己的偏好是将 core.autocrlf 设置为 code>在Windows上，如果所有项目中的Windows编辑器和其他文本文件处理工具是Unix行结束感知，否则设置为 core.autocrlf = true 用于Windows和 core.autocrlf = input 用于Unix。在任何情况下，这种方法过时的 .gitattributes 文件的优越方法。

My own preference is to set core.autocrlf to input on Windows if all the Windows editors and other text file processing tools on the project are Unix line ending aware, otherwise set it to core.autocrlf = true for Windows and core.autocrlf = input for Unix. In any case this approach is outmoded by the superior method of the .gitattributes file.

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

The .gitattributes file method processes files based on the file name and is maintained in all users environments as it is checked out into the working directory like .gitignore. The settings for as many file names and types as are relevant to your project should be added to .gitattributes. Your configuration then falls back onto the local core.autocrlf and core.safecrlf settings if the file name is not matched in .gitattributes. Adding * text=auto at the top of .gitattributes will cause git to do a best guess on file names which are not matched by the later .gitattributes settings.

此网页，注意您的行程结束< a>帮助我更好地理解问题。您可以阅读有关此问题的更多背景信息。

This web page, Mind the End of Your Line helped me understand the issue better. You might read for more background on the issue.

这篇关于Git core.safecrlf对具有相同行结尾的文件的不同行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！