不同操作系统之间的行结束转换如何与 git core.autocrlf 一起使用 [英] How line ending conversions work with git core.autocrlf between different operating systems

问题描述

我在 Stack Overflow 上阅读了许多不同的问题和答案，以及关于 core.autocrlf 设置如何工作的 git 文档.

这是我对阅读的理解:

Unix 和 Mac OSX(OSX 之前的版本使用 CR)客户端使用 LF 行结尾.
Windows 客户端使用 CRLF 行尾.

当客户端上的 core.autocrlf 设置为 true 时，git 存储库始终以 LF 行尾格式存储文件，并且客户端上文件中的行尾在客户端(即 Windows)检出/提交时来回转换使用非 LF 行结尾，无论客户端上的行结尾文件是什么格式(这与 Tim Clem 的定义不一致 - 请参阅下面的更新).

这是一个矩阵，它试图用问号记录 core.autocrlf 的输入"和假"设置的相同内容，其中我不确定行结束转换行为.

我的问题是:

1. 问号应该是什么?
2. 这个矩阵对于非问号"是否正确?

随着似乎形成共识，我将更新答案中的问号.

<前>core.autocrlf 值真输入假----------------------------------------------------------提交 |转变 ??新 |到 LF(转换为 LF?)(不转换?)提交 |转换成 ?不现有 |LF(转换为 LF?)转换结帐 |转换成 ?不现有 |CRLF(无转换?)转换

我并不是真的在寻找关于各种设置的利弊的意见.我只是在寻找数据，这些数据清楚地表明 git 如何在三种设置中的每一种下运行.

--

更新 04/17/2012:阅读Tim Clem 的文章 由 JJD 在评论中链接，我修改了unknown"中的一些值上表中的值，以及更改checkout existing |true 转换为 CRLF 而不是转换为客户端".以下是他给出的定义，比我在其他地方看到的任何内容都清楚:

core.autocrlf = false

<块引用>

这是默认设置，但鼓励大多数人更改此设置立即地.使用 false 的结果是 Git 永远不会乱在您的文件中以行结尾.您可以使用 LF 或 CRLF 签入文件或 CR 或这三者的一些随机组合，Git 不在乎.这个可以使差异更难阅读和合并更困难.大多数人在 Unix/Linux 世界中工作使用这个值，因为他们没有CRLF 问题，他们不需要 Git 做额外的工作文件写入对象数据库或写出到工作目录.

core.autocrlf = true

<块引用>

这意味着 Git 将处理所有文本文件并确保将该文件写入对象数据库时，将 CRLF 替换为 LF并在写入工作时将所有 LF 转回 CRLF目录.这是 Windows 上的推荐设置，因为它确保您的存储库可以在其他平台上使用，同时将 CRLF 保留在您的工作目录中.

core.autocrlf = 输入

<块引用>

这意味着 Git 将处理所有文本文件并确保将该文件写入对象时，将 CRLF 替换为 LF数据库.然而，它不会做相反的事情.当你阅读文件时退出对象数据库并将它们写入工作目录，他们仍然有 LF 来表示行尾.这个设置通常用于 Unix/Linux/OS X 以防止 CRLFs被写入存储库.这个想法是，如果你粘贴来自 Web 浏览器的代码，并且不小心将 CRLF 放入您的其中一个文件，Git 会确保在您编写时将它们替换为 LF到对象数据库.

Tim 的文章很棒，我唯一能想到的就是他认为存储库是 LF 格式，这不一定是正确的，尤其是对于仅适用于 Windows 的项目.

将 Tim 的文章与 jmlane 迄今为止得票最高的答案进行比较，显示了对真实和输入设置以及不同意见的完全一致在错误设置上.

解决方案

关于 core.autocrlf 如何工作的最佳解释可以在 gitattributes 手册页，位于 text 属性部分.

这就是 core.autocrlf 当前的工作方式(或者至少从我所知道的 v1.7.2 开始):

• core.autocrlf = true

1. 从存储库中检出的只有 LF 字符的文本文件在您的工作树中标准化为 CRLF；存储库中包含 CRLF 的文件将不会被触及
2. 在存储库中只有 LF 字符的文本文件在提交回存储库时从 CRLF 规范化为 LF.存储库中包含 CRLF 的文件将被原封不动地提交.

• core.autocrlf = 输入

1. 从存储库中签出的文本文件将在您的工作树中保留原始 EOL 字符.
2. 当提交回存储库时，工作树中带有 CRLF 字符的文本文件被规范化为 LF.

• core.autocrlf = false

1. core.eol 指示工作树文本文件中的 EOL 字符.
2. core.eol = native 默认情况下，这意味着工作树 EOL 将取决于 git 运行的位置:CRLF 在 Windows 机器上，或 LF 在 *nix 中.
3. 存储库 gitattributes 设置确定提交到存储库的 EOL 字符规范化(默认是规范化为 LF 字符).

我最近才研究这个问题，我也发现情况非常复杂.core.eol 设置肯定有助于阐明 git 如何处理 EOL 字符.

I've read a lot of different questions and answers on Stack Overflow as well as git documentation on how the core.autocrlf setting works.

This is my understanding from what I've read:

Unix and Mac OSX (pre-OSX uses CR) clients use LF line endings.
Windows clients use CRLF line endings.

When core.autocrlf is set to true on the client, the git repository always stores files in LF line ending format and line endings in files on the client are converted back and forth on check out / commit for clients (i.e. Windows) that use non-LF line endings, no matter what format the line endings files are on the client (this disagrees with Tim Clem's definition - see update below).

Here is a matrix that tries to document the same for the 'input' and 'false' settings of core.autocrlf with question marks where I'm not sure of line ending conversion behavior.

My questions are:

1. What should the question marks be?
2. Is this matrix correct for the "non-question marks"?

I'll update the question marks from the answers as consensus appears to be formed.

                       core.autocrlf value
            true            input              false
----------------------------------------------------------
commit   |  convert           ?                  ?
new      |  to LF      (convert to LF?)   (no conversion?)

commit   |  convert to        ?                 no 
existing |  LF         (convert to LF?)     conversion

checkout |  convert to        ?                 no
existing |  CRLF       (no conversion?)     conversion

I'm not really looking for opinions on the pros and cons of the various settings. I'm just looking for data which makes it clear how to expect git to operate with each of the three settings.

--

Update 04/17/2012: After reading the article by Tim Clem linked by JJD in the comments, I have modified some of the values in the "unknown" values in the table above, as well as changing "checkout existing | true to convert to CRLF instead of convert to client". Here are the definitions he gives, which are more clear than anything I've seen elsewhere:

core.autocrlf = false

This is the default, but most people are encouraged to change this immediately. The result of using false is that Git doesn’t ever mess with line endings on your file. You can check in files with LF or CRLF or CR or some random mix of those three and Git does not care. This can make diffs harder to read and merges more difficult. Most people working in a Unix/Linux world use this value because they don’t have CRLF problems and they don’t need Git to be doing extra work whenever files are written to the object database or written out into the working directory.

core.autocrlf = true

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database and turn all LF back into CRLF when writing out into the working directory. This is the recommended setting on Windows because it ensures that your repository can be used on other platforms while retaining CRLF in your working directory.

core.autocrlf = input

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database. It will not, however, do the reverse. When you read files back out of the object database and write them into the working directory they will still have LFs to denote the end of line. This setting is generally used on Unix/Linux/OS X to prevent CRLFs from getting written into the repository. The idea being that if you pasted code from a web browser and accidentally got CRLFs into one of your files, Git would make sure they were replaced with LFs when you wrote to the object database.

Tim's article is excellent, the only thing I can think of that is missing is that he assumes the repository is in LF format, which is not necessarily true, especially for Windows only projects.

Comparing Tim's article to the highest voted answer to date by jmlane shows perfect agreement on the true and input settings and disagreement on the false setting.

解决方案

The best explanation of how core.autocrlf works is found on the gitattributes man page, in the text attribute section.

This is how core.autocrlf appears to work currently (or at least since v1.7.2 from what I am aware):

• core.autocrlf = true

1. Text files checked-out from the repository that have only LF characters are normalized to CRLF in your working tree; files that contain CRLF in the repository will not be touched
2. Text files that have only LF characters in the repository, are normalized from CRLF to LF when committed back to the repository. Files that contain CRLF in the repository will be committed untouched.

• core.autocrlf = input

1. Text files checked-out from the repository will keep original EOL characters in your working tree.
2. Text files in your working tree with CRLF characters are normalized to LF when committed back to the repository.

• core.autocrlf = false

1. core.eol dictates EOL characters in the text files of your working tree.
2. core.eol = native by default, which means working tree EOLs will depend on where git is running: CRLF on a Windows machine, or LF in *nix.
3. Repository gitattributes settings determines EOL character normalization for commits to the repository (default is normalization to LF characters).

I've only just recently researched this issue and I also find the situation to be very convoluted. The core.eol setting definitely helped clarify how EOL characters are handled by git.

这篇关于不同操作系统之间的行结束转换如何与 git core.autocrlf 一起使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！