这本质上是关于.gitattributes配置中* text=auto和* text=auto eol=lf之间的差异的问题的后续："*text＝auto"；和"*"text＝auto-eol＝lf"？
我想我理解Git是如何工作的，但我想确认一下，因为文档很混乱。
text属性状态的文档：
此属性启用并控制行尾规范化。当文本文件被规范化时，其行尾在存储库中被转换为LF。要控制工作目录中使用的行尾样式，请为单个文件使用eol属性，为所有文本文件使用core.eol配置变量。请注意，将core.autocrlf设置为true或input会覆盖core.eol(请参阅git-config[1]中这些选项的定义(。
因此，如果您使用* text=auto，那么听起来Git默认情况下强制执行LF，从而使* text=auto eol=lf变得多余。
然而，这句话的第二个粗体部分让我感到困惑：Git是否尊重core.autocrlf或core.eol？我使用PowerShell和Git2.16.1:在Windows机器上测试了这一点
- 运行
git config --global core.autocrlf false和git config --global core.eol crlf。后者不是你通常想要的，但对这个实验来说，看看Git是否会接受它是很有用的 - 使用记事本创建一个包含多行内容的文本文件。该文件应具有
CRLF行结尾 - 初始化同一目录中的Git repo
- 将文件添加到Git的索引中
- 运行
git ls-files --eol，观察文件在索引和工作树中都有CRLF - 添加一个带有
* text = auto的.gitattributes文件。承诺 - 运行
git add --renormalize .以重新规范以前提交的文件 - 运行
git status。请注意，该文件已暂存以供提交 - 提交文件后，运行
git ls-files --eol以观察文件现在在索引中使用LF
因此，尽管我设置了core.eol=crlf并关闭了core.autocrlf，Git仍然对行尾强制执行LF。
问题：文档是否具有误导性？text=auto是否始终强制执行LF？
我想我已经想通了：
-
core.autocrlf和core.eol只影响工作树中的行尾，而不影响Git的索引(启用规范化时将始终使用LF(或代码的远程副本。因此CCD_ 29。 -
.gitattributes中的eol属性意味着text，这意味着它在索引中强制执行LF，以及在工作目录中为eol设置的任何值。示例：eol=crlf表示index = LF和working tree = CRLF。
所以文档有点误导，因为text=auto不依赖于core.autocrlf或core.eol——它总是强制索引使用LF行结尾。除非配置core.autocrlf、core.eol或使用eol属性，否则工作树中的行尾将保持原样。