Git*text=auto在gitattributes文件和行尾中

根据这篇文章： 如果.gittributes文件中包含以下内容，则文本文件的行尾将转换为LF：

* text=auto

warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.

我刚刚在本地存储库上测试了此功能：

$ git add -A
warning: LF will be replaced by CRLF in [bla]/.gitattributes.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/.gitignore.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in [bla].csproj.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in 

但是在那里它说它将转换为CRLF。在上面的帖子中，它说它将转换为LF，这在本测试中并非如此

看来：

* text=auto

将根据操作系统转换为行尾类型（windows为CRLF，linux为LF）。但这并不是本文所描述的：

根据以下评论/回答，似乎警告是由以下内容引起的：

* text=auto

在.gittributes文件中：

* text=auto

warning: LF will be replaced by CRLF in [bla]/README.md.
The file will have its original line endings in your working directory.

实际上，这意味着当您执行签出操作时（下次将文件从存储库签出到工作目录时），当前带有LF结尾的文本文件将转换为具有CRLF

警告没有说明在检查时，in行将有LF结尾，这是文档中所说的：

设置为字符串值“自动”

---

当文本设置为“自动”时，路径被标记为自动行结束标准化。如果Git确定内容是文本，那么在签入时它的行尾会被规范化为LF。

这条消息有点让人困惑

Git将在任何时候警告您，它不会以与当前行结束转换设置相同的方式往返您的文件。这个警告不是因为Git要将CRLFs放入存储库（不是）-这个警告是因为Git要签出的文件与当前磁盘上的文件不同

无论出于何种原因，工作目录中的文件都有Unix风格的行尾（或Unix和Windows风格的混合）。您应该能够通过十六进制编辑器看到这一点。例如，我有一个具有Unix样式行结尾的文件：

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007   

C:\Temp>git ls-files --stage
100644 4effa19f4f75f846c3229b9dbdbad14eff362f32 0       foo

C:\Temp>git cat-file blob 4effa19 | hexdump /C
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

如果我将文件添加到我的存储库中（使用

*text=auto

或

core.autocrlf=true

）：

正如git所指出的，我当前工作目录中的文件有其原始（Unix样式）行结尾：

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007   

C:\Temp>git ls-files --stage
100644 4effa19f4f75f846c3229b9dbdbad14eff362f32 0       foo

C:\Temp>git cat-file blob 4effa19 | hexdump /C
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

但存储库中的文件也有Unix样式的行尾：

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

C:\Temp>hexdump /C foo
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007   

C:\Temp>git ls-files --stage
100644 4effa19f4f75f846c3229b9dbdbad14eff362f32 0       foo

C:\Temp>git cat-file blob 4effa19 | hexdump /C
00000000  68 65 6c 6c 6f 21 0a                              |hello!.|
00000007

但是，如果我要求git创建文件内容，那么它将创建一个不同的文件-一个具有CRLF行结尾的文件，这就是警告实际指示的内容：

C:\Temp>del foo

C:\Temp>git checkout -f foo

C:\Temp>hexdump -C foo
00000000  68 65 6c 6c 6f 21 0d 0a                           |hello!..|
00000008

---

因此，此消息只是警告您，此文件的下一次签出实际上与您当前磁盘上的内容不匹配。在这种情况下，这可能是无害的，但如果您添加的文件中的行尾配置与其匹配非常关键，则这将是非常糟糕的。

可能重复相关的“是”，但不是我在此要求的。这里是关于特定警告消息的含义，并将其与公共文档中的描述进行比较。警告不是由

text=auto

引起的，而是

text=auto

有效地与您之前设置的其他选项交互。另一个问题涉及其他选项。好吧，那么这个警告实际上是在您签出时发出的，与公共文档中的签入规则无关？似乎我编辑的文章。提交和签出需要整体考虑，你的过滤器和行尾设置都适用于这两个方面。这是警告你的适当时机，因为这是你唯一可以采取行动纠正错误的时候。