不同操作系统之间如何使用 git core.autocrlf 进行行尾转换

How line ending conversions work with git core.autocrlf between different operating systems

提问by Michael Maddox

I've read a lot of different questions and answers on Stack Overflow as well as gitdocumentation on how the core.autocrlfsetting works.

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

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.

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

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).

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

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.

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

My questions are:

我的问题是：

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

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

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.

我并不是真的在寻找关于各种设置的利弊的意见。我只是在寻找数据，它清楚地表明如何期望 git 使用三种设置中的每一种进行操作。

--

——

Update 04/17/2012: After reading the article by Tim Clemlinked 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:

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

core.autocrlf = false

core.autocrlf = 假

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.

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

core.autocrlf = true

core.autocrlf = 真

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.

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

core.autocrlf = input

core.autocrlf = 输入

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.

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

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.

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

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.

将 Tim 的文章与 jmlane 迄今为止投票最高的答案进行比较，显示出对 true 和 input 设置的完全一致以及对 false 设置的分歧。

回答by jmlane

The best explanation of how core.autocrlfworks is found on the gitattributesman page, in the textattribute section.

core.autocrlf在gitattributes手册页的text属性部分中可以找到有关如何工作的最佳解释。

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

这就是core.autocrlf目前的工作方式（或者至少从我所知道的 v1.7.2 开始）：

• core.autocrlf = true
  1. Text files checked-out from the repository that have only LFcharacters are normalized to CRLFin your working tree; files that contain CRLFin the repository will not be touched
  2. Text files that have only LFcharacters in the repository, are normalized from CRLFto LFwhen committed back to the repository. Files that contain CRLFin 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 CRLFcharacters are normalized to LFwhen committed back to the repository.
• core.autocrlf = false
  1. core.eoldictates EOL characters in the text files of your working tree.
  2. core.eol = nativeby default, which means Windows EOLs are CRLFand *nix EOLs are LFin working trees.
  3. Repository gitattributessettings determines EOL character normalization for commits to the repository (default is normalization to LFcharacters).

• core.autocrlf = true
  1. 从存储库中检出的只有LF字符的文本文件CRLF在您的工作树中被规范化；CRLF不会触及存储库中包含的文件
  2. LF存储库中只有字符的文本文件在提交回存储库时从CRLF到标准化LF。包含CRLF在存储库中的文件将原封不动地提交。
• core.autocrlf = input
  1. 从存储库签出的文本文件将在您的工作树中保留原始 EOL 字符。
  2. 工作树中带有CRLF字符的文本文件在LF提交回存储库时被规范化。
• core.autocrlf = false
  1. core.eol指示工作树的文本文件中的 EOL 字符。
  2. core.eol = native默认情况下，这意味着 Windows EOLCRLF和 *nix EOLLF在工作树中。
  3. 存储库gitattributes设置确定提交到存储库的 EOL 字符规范化（默认为LF字符规范化）。

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

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

回答by Adi Shavit

The issue of EOLs in mixed-platform projects has been making my life miserable for a long time. The problems usually arise when there are already files with different and mixed EOLs alreadyin the repo. This means that:

混合平台项目中的 EOL 问题已经让我的生活痛苦了很长时间。当已经有不同的和混合EOLS文件通常出现的问题已经在回购协议。这意味着：

1. The repo may have different files with different EOLs
2. Some files in the repo may have mixed EOL, e.g. a combination of CRLFand LFin the same file.

1. 存储库可能具有不同 EOL 的不同文件
2. 存储库中的某些文件可能具有混合的 EOL，例如同一文件中的CRLF和的组合LF。

How this happens is not the issue here, but it does happen.

这是如何发生的不是这里的问题，但它确实发生了。

I ran some conversion tests on Windows for the various modes and their combinations.
Here is what I got, in a slightly modified table:

我在 Windows 上针对各种模式及其组合进行了一些转换测试。
这是我得到的，在一个稍微修改过的表格中：

                 | Resulting conversion when       | Resulting conversion when 
                 | committing files with various   | checking out FROM repo - 
                 | EOLs INTO repo and              | with mixed files in it and
                 |  core.autocrlf value:           | core.autocrlf value:           
--------------------------------------------------------------------------------
File             | true       | input      | false | true       | input | false
--------------------------------------------------------------------------------
Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is

As you can see, there are 2 cases when conversion happens on commit (3 left columns). In the rest of the cases the files are committed as-is.

如您所见，有 2 种情况是在提交时发生转换（左 3 列）。在其余情况下，文件按原样提交。

Upon checkout (3 right columns), there is only 1 case where conversion happens when:

结帐时（右 3 列），只有 1 种情况会在以下情况下发生转换：

1. core.autocrlfis trueand
2. the file in the repo has the LFEOL.

1. core.autocrlf是true和
2. 存储库中的文件具有LFEOL。

Most surprising for me, and I suspect, the cause of many EOL problems is that there is no configuration in which mixed EOL like CRLF+LFget normalized.

对我来说最令人惊讶的是，我怀疑，许多 EOL 问题的原因是没有配置像CRLF+这样的混合 EOLLF得到规范化。

Note also that "old" Mac EOLs of CRonly also never get converted.
This means that if a badly written EOL conversion script tries to convert a mixed ending file with CRLFs+LFs, by just converting LFs to CRLFs, then it will leave the file in a mixed mode with "lonely" CRs wherever a CRLFwas converted to CRCRLF.
Git will then not convert anything, even in truemode, and EOL havoc continues. This actually happened to me and messed up my files really badly, since some editors and compilers (e.g. VS2010) don't like Mac EOLs.

另请注意，CR只有“旧”Mac EOL也永远不会被转换。
这意味着如果一个写得不好的 EOL 转换脚本试图用CRLFs+ LFs转换一个混合结尾的文件，只需将LFs转换为CRLFs，那么CR无论 aCRLF被转换为CRCRLF.
Git 将不会转换任何内容，即使在true模式下，EOL 浩劫仍在继续。这实际上发生在我身上并且非常严重地弄乱了我的文件，因为一些编辑器和编译器（例如 VS2010）不喜欢 Mac EOL。

I guess the only way to really handle these problems is to occasionallynormalize the whole repo by checking out all the files in inputor falsemode, running a proper normalization and re-committing the changed files (if any). On Windows, presumably resume working with core.autocrlf true.

我想真正处理这些问题的唯一方法是偶尔通过检出input或false模式下的所有文件，运行适当的规范化并重新提交更改的文件（如果有）来规范整个存储库。在 Windows 上，大概可以继续使用core.autocrlf true.

回答by VonC

Things are about to change on the "eol conversion" front, with the upcoming Git 1.7.2:

随着即将推出的 Git 1.7.2，“eol 转换”方面的情况即将发生变化：

A new config setting core.eolis being added/evolved:

core.eol正在添加/改进新的配置设置：

This is a replacement for the 'Add "core.eol" config variable' commit that's currently in pu(the last one in my series).
Instead of implying that "core.autocrlf=true" is a replacement for "* text=auto", it makes explicit the fact that autocrlfis only for users who want to work with CRLFs in their working directory on a repository that doesn't have text file normalization.
When it is enabled, "core.eol" is ignored.

Introduce a new configuration variable, "core.eol", that allows the user to set which line endings to use for end-of-line-normalized files in the working directory.
It defaults to "native", which means CRLF on Windows and LF everywhere else. Note that "core.autocrlf" overrides core.eol.
This means that:

[core]
  autocrlf = true

puts CRLFs in the working directory even if core.eolis set to "lf".

core.eol:

Sets the line ending type to use in the working directory for files that have the textproperty set.
Alternatives are 'lf', 'crlf' and 'native', which uses the platform's native line ending.
The default value is native.

这是对core.eol当前pu（我系列中的最后一个）提交的“添加“ ”配置变量的替代。
它没有暗示“ core.autocrlf=true”是“ ”的替代品* text=auto，而是明确表示autocrlf仅适用于希望在没有文本文件规范化的存储库上的工作目录中使用 CRLF 的用户。
启用时，“core.eol”将被忽略。

引入一个新的配置变量“ core.eol”，它允许用户设置哪些行结尾用于工作目录中的行尾规范化文件。
它默认为“ native”，这意味着 Windows 上的 CRLF 和其他地方的 LF。请注意，“ core.autocrlf” 会覆盖core.eol.
这意味着：

[core]
  autocrlf = true

即使core.eol设置为“ lf”，也会将 CRLF 放在工作目录中。

core.eol:

设置在工作目录中使用的行结束类型，用于text设置了属性的文件。
替代选项是 'lf'、'crlf' 和 'native'，它们使用平台的本地行结尾。
默认值为native。

---

---

Other evolutions are being considered:

正在考虑其他演变：

For 1.8, I would consider making core.autocrlfjust turn on normalization and leave the working directory line ending decision to core.eol, but that willbreak people's setups.

对于 1.8，我会考虑core.autocrlf只打开规范化并将工作目录行结束决定留给 core.eol，但这会破坏人们的设置。

---

---

git 2.8 (March 2016) improves the way core.autocrlfinfluences the eol:

git 2.8（2016 年 3 月）改进了core.autocrlf影响 eol的方式：

See commit 817a0c7(23 Feb 2016), commit 6e336a5, commit df747b8, commit df747b8(10 Feb 2016), commit df747b8, commit df747b8(10 Feb 2016), and commit 4b4024f, commit bb211b4, commit 92cce13, commit 320d39c, commit 4b4024f, commit bb211b4, commit 92cce13, commit 320d39c(05 Feb 2016) by Torsten B?gershausen (tboegi).
^{(Merged by Junio C Hamano -- gitster--in commit c6b94eb, 26 Feb 2016)}

见提交817a0c7（2016年2月23日），提交6e336a5，提交df747b8，提交df747b8（2016年2月10日），提交df747b8，提交df747b8（2016年2月10日），以及提交4b4024f，提交bb211b4，提交92cce13，提交320d39c，提交4b4024f，提交 bb211b4，提交 92cce13，提交 320d39c（2016 年 2 月 5 日）由Torsten B?gershausen ( tboegi)。
^{（由Junio C gitsterHamano合并-- --在提交 c6b94eb 中, 2016 年 2 月 26 日）}

convert.c: refactor crlf_action

Refactor the determination and usage of crlf_action.
Today, when no "crlf" attribute are set on a file, crlf_actionis set to CRLF_GUESS. Use CRLF_UNDEFINEDinstead, and search for "text" or "eol" as before.

Replace the old CRLF_GUESSusage:

convert.c: 重构 crlf_action

重构crlf_action.
今天，当没有crlf在文件上设置“ ”属性时，crlf_action设置为 CRLF_GUESS. CRLF_UNDEFINED改为使用，并像以前一样搜索“ text”或“ eol”。

替换旧CRLF_GUESS用法：

CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

Make more clear, what is what, by defining:

通过定义更清楚，什么是什么：

- CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

---

---

As torekadds in the comments:

正如torek在评论中补充的那样：

all these translations (any EOL conversion from eol=or autocrlfsettings, and "clean" filters) are run when files move from work-tree to index, i.e., during git addrather than at git committime.
(Note that git commit -aor --onlyor --includedo add files to the index at that time, though.)

当文件从工作树移动到索引时，即在期间而不是在时间时，运行所有这些转换（来自eol=或autocrlf设置的任何 EOL 转换，以及“ clean”过滤器）。 （不过，请注意or或do 当时将文件添加到索引中。）git addgit commit
git commit -a--only--include

For more on that, see "What is difference between autocrlf and eol".

有关更多信息，请参阅“ autocrlf 和 eol 之间的区别是什么”。

回答by pratt

core.autocrlfvalue does not depend on OS type but on Windows default value is trueand for Linux - input. I explored 3 possible values for commit and checkout cases and this is the resulting table:

core.autocrlf值不取决于操作系统类型，但在 Windows 上，默认值为true和 对于 Linux - input. 我探索了提交和结帐案例的 3 个可能值，这是结果表：

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

回答by Carl

Here is my understanding of it so far, in case it helps someone.

到目前为止，这是我对它的理解，以防它对某人有所帮助。

core.autocrlf=trueand core.safecrlf = true

core.autocrlf=true和 core.safecrlf = true

You have a repository where all the line endings are the same, but you work on different platforms. Git will make sure your lines endings are converted to the default for your platform. Why does this matter? Let's say you create a new file. The text editor on your platform will use its default line endings. When you check it in, if you don't have core.autocrlf set to true, you've introduced a line ending inconsistency for someone on a platform that defaults to a different line ending. I always set safecrlf too because I would like to know that the crlf operation is reversible. With these two settings, git is modifying your files, but it verifies that the modifications are reversible.

您有一个所有行结尾都相同的存储库，但您在不同的平台上工作。Git 将确保您的行尾转换为您平台的默认值。为什么这很重要？假设您创建了一个新文件。您平台上的文本编辑器将使用其默认行尾。当您签入时，如果您没有将 core.autocrlf 设置为 true，那么您已经为平台上的某人引入了行尾不一致，该平台默认为不同的行尾。我也总是设置 safecrlf，因为我想知道 crlf 操作是可逆的。通过这两个设置，git 正在修改您的文件，但它会验证修改是否可逆。

core.autocrlf=false

core.autocrlf=false

You have a repository that already has mixed line endingschecked in and fixing the incorrect line endings could break other things. Its best not to tell git to convert line endings in this case, because then it will exacerbate the problem it was designed to solve - making diffs easier to read and merges less painful. With this setting, git doesn't modify your files.

您有一个已经签入混合行尾的存储库，修复不正确的行尾可能会破坏其他事情。在这种情况下最好不要告诉 git 转换行尾，因为那样会加剧它旨在解决的问题 - 使差异更易于阅读并减少合并的痛苦。使用此设置，git 不会修改您的文件。

core.autocrlf=input

core.autocrlf=input

I don't use this because the reason for this is to cover a use case where you created a file that has CRLF line endings on a platform that defaults to LF line endings. I prefer instead to make my text editor always save new files with the platform's line ending defaults.

我不使用它，因为这样做的原因是为了涵盖一个用例，在该用例中，您在默认为 LF 行结尾的平台上创建了一个具有 CRLF 行结尾的文件。我更喜欢让我的文本编辑器始终使用平台的行尾默认值保存新文件。

回答by ViciOs

No, the @jmlane answer is wrong.

不，@jmlane 的答案是错误的。

For Checkin (git add, git commit):

对于Checkin (git add, git commit)：

1. if textproperty is Set, Set value to 'auto', the conversion happens enen the file has been committed with 'CRLF'
2. if textproperty is Unset:nothing happens, enen for Checkout
3. if textproperty is Unspecified, conversion depends on core.autocrlf
   1. if autocrlf = input or autocrlf = true, the conversion only happens when the file in the repository is 'LF', if it has been 'CRLF', nothing will happens.
   2. if autocrlf = false, nothing happens

1. 如果textproperty is Set, Set value to 'auto'，则转换发生 enen 文件已使用 'CRLF' 提交
2. 如果text属性是Unset：什么也没发生，enen forCheckout
3. 如果text属性是Unspecified，则转换取决于core.autocrlf
   1. 如果autocrlf = input or autocrlf = true，则转换仅在存储库中的文件为 'LF' 时发生，如果为 'CRLF'，则不会发生任何事情。
   2. 如果autocrlf = false，什么也没有发生

For Checkout:

对于Checkout：

1. if textproperty is Unset: nothing happens.
2. if textproperty is Set, Set value to 'auto: it depends on core.autocrlf, core.eol.
   1. core.autocrlf = input : nothing happens
   2. core.autocrlf = true : the conversion only happens when the file in the repository is 'LF', 'LF' -> 'CRLF'
   3. core.autocrlf = false : the conversion only happens when the file in the repository is 'LF', 'LF' -> core.eol
3. if textproperty is Unspecified, it depends on core.autocrlf.
   1. the same as 2.1
   2. the same as 2.2
   3. None, nothing happens, core.eol is not effective when textproperty is Unspecified

1. 如果text属性是Unset：没有任何反应。
2. 如果text属性是Set, Set value to 'auto：它取决于core.autocrlf, core.eol。
   1. core.autocrlf = 输入：没有任何反应
   2. core.autocrlf = true ：转换仅在存储库中的文件为 'LF', 'LF' -> 'CRLF' 时发生
   3. core.autocrlf = false ：转换仅在存储库中的文件为 'LF', 'LF' 时发生 -> core.eol
3. 如果text属性是Unspecified，则取决于core.autocrlf.
   1. 一样 2.1
   2. 一样 2.2
   3. 无，没有任何反应，core.eol 在text属性为Unspecified

Default behavior

默认行为

So the Default behavior is textproperty is Unspecifiedand core.autocrlf = false:

所以默认行为是text属性是Unspecified和core.autocrlf = false：

1. for checkin, nothing happens
2. for checkout, nothing happens

1. 对于签到，没有任何反应
2. 结帐时，没有任何反应

Conclusions

结论

1. if textproperty is set, checkin behavior is depends on itself, not on autocrlf
2. autocrlf or core.eol is for checkout behavior, and autocrlf > core.eol

1. 如果text设置了属性，则签入行为取决于自身，而不取决于 autocrlf
2. autocrlf 或 core.eol 用于结帐行为，并且 autocrlf > core.eol

回答by Luc Depoorter

Did some tests both on linux and windows. I use a test file containing lines ending in LF and also lines ending in CRLF.
File is committed , removed and then checked out. The value of core.autocrlf is set before commit and also before checkout. The result is below.

在 linux 和 windows 上做了一些测试。我使用包含以 LF 结尾的行和以 CRLF 结尾的行的测试文件。
文件被提交、删除然后签出。core.autocrlf 的值在提交之前和签出之前设置。结果如下。

commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF