git - 不同操作系统之间的行结束转换如何与 git core.autocrlf 一起工作

Question

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

这是我读到的内容的理解:

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

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

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

我的问题是:

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

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

                       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?)     conversioncheckout |  convert to        ?                 noexisting |  CRLF       (no conversion?)     conversion

我并不是真的在寻找关于各种设置的优缺点的意见。我只是在寻找数据，这些数据可以清楚地说明如何期望 git 使用三种设置中的每一种进行操作。

--

2012 年 4 月 17 日更新:阅读后the article by Tim Clem JJD 在评论中链接，我修改了上表中“未知”值中的一些值，以及更改“checkout existing | true 以转换为 CRLF 而不是转换为客户端”。以下是他给出的定义，比我在其他地方看到的任何定义都清晰:

core.autocrlf = false

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

core.autocrlf = true

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

core.autocrlf = 输入

This means that Git will process all text files and make sure thatCRLF is replaced with LF when writing that file to the objectdatabase. It will not, however, do the reverse. When you read filesback out of the object database and write them into the workingdirectory they will still have LFs to denote the end of line. Thissetting is generally used on Unix/Linux/OS X to prevent CRLFs fromgetting written into the repository. The idea being that if you pastedcode from a web browser and accidentally got CRLFs into one of yourfiles, Git would make sure they were replaced with LFs when you wroteto the object database.

Tim 的文章非常好，我唯一能想到的是他假设存储库是 LF 格式，这不一定是正确的，尤其是对于仅限 Windows 的项目。

将 Tim 的文章与投票最高的文章进行比较 answer to date by jmlane 在 true 和 input 设置上完全一致，在 false 设置上存在分歧。

Answer 1

关于 core.autocrlf 工作原理的最佳解释可以在 gitattributes 上找到。手册页，在 text attribute section .

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

• core.autocrlf = true

1. 从存储库中 check out 的只有 LF 字符的文本文件在您的工作树中被规范化为 CRLF；存储库中包含 CRLF 的文件将不会被触及
2. 存储库中只有 LF 字符的文本文件在提交回存储库时从 CRLF 规范化为 LF。存储库中包含 CRLF 的文件将不受影响地提交。

• core.autocrlf = input

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

• core.autocrlf = false

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

我最近才研究这个问题，我也觉得情况很复杂。 core.eol 设置无疑有助于阐明 git 如何处理 EOL 字符。