有一个.gitattributes条目
* text=auto
签出文本文件时使用什么行分隔符？该文档指出：
设置为字符串值“自动”
当文本设置为“自动”时，该路径被标记为自动行尾转换。如果Git确定内容为文本，则其行尾在签入时将转换为LF。使用CRLF提交文件后，不会进行任何转换。
未指定
如果未指定text属性，则Git使用core.autocrlf配置变量来确定是否应转换文件。
在我看来，万一text=auto core.autocrlf没关系。我对吗？
在我看来，在
text=auto[in中.gitattributes，具有]core.autocrlf[在配置中]的情况并不重要。我对吗？
大多。该git config文档现在说core.autocrlf：
将此变量设置为“ true”与将
text所有文件的属性设置为“ auto”以及将core.eol设置为“ crlf”相同。...该变量可以设置为input，在这种情况下，不执行输出转换。
令人困惑的是git config，文件编制core.eol本身就这样说：
设置结束类型的工作目录中使用了具有文件行
text属性集时core.autocrlf是假的[我告诉你什么什么时候将其设置为true或input] ...查看gitattributes（5）有关的更多信息行尾转换。
（黑体字和方括号中的文本）。然而，的说明core.autocrlf会谈有关有效设置core.eol，所以什么也当发生core.autocrlf或者是true或input，并 core.eol设置为crlf？
如果我们转到gitattributes文档，则会发现此短语已隐藏：
要控制在工作目录中使用哪种行尾样式，请
eol对单个文件使用属性，core.eol对所有文本文件使用配置变量。需要注意的是core.autocrlf覆盖core.eol
因此，如果您未设置core.autocrlf，则不会覆盖core.eol任何一个。这意味着您选择的任何内容都core.eol将应用为默认设置。但是，如果你不设置core.autocrlf，不管你选择的core.eol设置被忽略！
Git中的实际源代码非常曲折（并且多年来发生了许多变化）。但是，有些事情可以说在所有Git变体中都是正确的：
转换1通常发生在两个地方：文件从索引复制到工作树（“输出”阶段），或文件从工作树复制到索引（“输入”阶段） ）。输出端复制发生在git checkout和期间git checkout-index，这两个复制都将文件从索引复制到工作树。输入端复制发生在期间git add，将文件从工作树复制到索引。
视为“二进制”的文件不会被修改。被认为是“文本”的文件是修改的候选者。
因此，* text=auto意味着所有文件都将成为修改的候选文件，并且core.autocrlf具有相同的效果。但是究竟要进行什么修改？这部分很棘手。假设两个不同的配置文档部分中的上述引用对于所有版本的Git都是正确的：
.gitattributes具有特定 设置的设置eol=，则该core.eol设置无关紧要。但这与是否.gitattributes设置无关text=。eol=设置，您的有效core.eol设置都会控制这些转换是什么。因此，由于core.autocrlf可以更改有效core.eol设置，并且您可以忽略为某些文件设置特定设置，因此即使您已经为所有文件设置了设置text，core.autocrlf设置也就像将core.eol设置更改为。（如果设置为，将需要仔细测试，这会发生什么情况。）crlftext=autocore.autocrlfinput
1这个词通常在这里，因为这是关于文件在Git进出中转换的位置。但是，对于某些操作（例如git diff针对工作树或git merge启用“规范化”），Git必须执行“虚拟签入”或“虚拟签入和签出”，在这种情况下，Git会做一些额外的工作转换。不幸的是，这就是为什么Git中的实际代码如此曲折的原因。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句