.gitattributes:text = auto是否仍使用core.autocrlf来检测EOL [英] .gitattributes: does text=auto still uses core.autocrlf to detect EOL

问题描述

带有.gitattributes条目

 * text=auto

签出文本文件时使用什么行分隔符? 文档指出:

what line separators are used when checking out the text files? The documentation states:

设置为字符串值自动"

当文本设置为自动"时，该路径被标记为自动行尾转换.如果Git决定内容为文本，则其内容为 行尾在签入时转换为LF.当文件已经被 使用CRLF进行提交，则不会进行任何转换.

When text is set to "auto", the path is marked for automatic end-of-line conversion. If Git decides that the content is text, its line endings are converted to LF on checkin. When the file has been committed with CRLF, no conversion is done.

未指定

如果未指定text属性，则Git使用core.autocrlf配置变量来确定是否应转换文件.

If the text attribute is unspecified, Git uses the core.autocrlf configuration variable to determine if the file should be converted.

在我看来，在text=auto core.autocrlf的情况下没关系.我说的对吗?

This sounds to me that in case of text=auto core.autocrlf does not matter. Am I right?

推荐答案

在我看来，对于text=auto [在.gitattributes中，具有] core.autocrlf [在配置中]并不重要.我说的对吗?

This sounds to me that in case of text=auto [in .gitattributes, having] core.autocrlf [in the configuration] does not matter. Am I right?

大部分. git config文档现在说，对于core.autocrlf:

将此变量设置为"true"与在所有文件上将text属性设置为"auto"以及将core.eol设置为"crlf"相同. ...该变量可以设置为 input ，在这种情况下，不执行输出转换.

Setting this variable to "true" is the same as setting the text attribute to "auto" on all files and core.eol to "crlf". ... This variable can be set to input, in which case no output conversion is performed.

对于core.eol本身，git config无效表示，令人困惑的只是几行了:

Confusingly, just a few lines earlier, the git config documetnation says, for core.eol itself:

设置在工作目录中用于text属性集的文件的行尾类型当core.autocrlf为false 时[我告诉你没什么关于何时将其设置为true或input] ...请参见

Sets the line ending type to use in the working directory for files that have the text property set when core.autocrlf is false [and I tell you nothing about when it set to true or to input]... See gitattributes(5) for more information on end-of-line conversion.

(黑体字和方括号中的文本).但是，core.autocrlf的描述是关于有效设置core.eol的，因此，当core.autocrlf是true或input，和时，会发生什么 core.eol设置为crlf?

(boldface and bracketed text mine). And yet, the description of core.autocrlf talks about effectively setting core.eol, so what does happen when core.autocrlf is either true or input, and core.eol is set to crlf?

如果我们转向 gitattributes文档 ，我们发现此短语已隐藏:

If we turn to the gitattributes documentation, we find this phrase hidden away:

要控制在工作目录中使用哪种行尾样式，请对单个文件使用eol属性，对所有文本文件使用core.eol配置变量.请注意，core.autocrlf会覆盖core.eol

To control what line ending style is used in the working directory, use the eol attribute for a single file and the core.eol configuration variable for all text files. Note that core.autocrlf overrides core.eol

因此，如果您不设置core.autocrlf，则此也不会覆盖core.eol.这意味着您为core.eol选择的 均为默认设置.但是，如果您要做设置了core.autocrlf，则为core.eol设置选择的任何内容都会被忽略！

So, if you don't set core.autocrlf, this doesn't override core.eol either. This means that whatever you choose for core.eol applies as a default. But if you do set core.autocrlf, whatever you choose for a core.eol setting gets ignored!

Git内的实际源代码非常曲折(多年来已经发生了许多变化).但是，有些事情可以说在所有Git变体中都是正确的:

The actual source code inside Git is terribly twisty (and has undergone numerous changes over the years). There are a few things that one can say that are true across all Git variants, though:

1. 转换通常 ¹ 仅发生在两个地方:当文件从索引复制到工作树时(输出"阶段)，或者文件从索引的工作树(输入"阶段).输出端复制发生在git checkout和git checkout-index期间，它们都将文件从索引复制到工作树.输入端复制发生在git add期间，它将文件从工作树复制到索引.

1. Conversions normally¹ occur in just two places: when a file is copied from the index to the work-tree (the "output" phase), or when a file is copied from the work-tree to the index (the "input" phase). The output side copies happen during git checkout and git checkout-index, both of which copy files from the index to the work-tree. The input side copies happen during git add, which copies files from the work-tree to the index.

被认为是二进制"的文件不会被修改.认为是文本"的文件可以进行修改.

A file considered to be "binary" does not get modified. A file considered to be "text" is a candidate for modification.

因此，* text=auto意味着所有文件都将成为修改的候选文件，并且core.autocrlf具有相同的效果.但是到底应用了什么修改?这部分很棘手.假设上述两个不同的配置文档部分中的引用对于所有版本的Git都是正确的:

So, * text=auto means that all files become candidates for modification, and core.autocrlf has the same effect. But exactly what modification is applied? That part is tricky. Assuming the above quotes from the two different configuration documentation sections are correct for all versions of Git:

• 如果对于任何特定的 path ，您有一个.gitattributes设置且具有 specific eol=，则core.eol设置无关紧要.但这与是否为text=设置.gitattributes无关.
• 因此，无论您忘记了什么特定的eol=设置，您的有效core.eol设置都会控制这些转换是什么.

• If, for any particular path, you have a .gitattributes setting with a specific eol=, the core.eol setting does not matter. But this is independent of whether you have a .gitattributes setting for text=.
• Therefore, wherever you forgot to also have a specific eol= settting, your effective core.eol setting controls what those conversions are.

因此，由于core.autocrlf可以更改有效的core.eol设置，因此和您可以忽略为某些text文件设置特定于 的设置，其中core.autocrlf设置就像将core.eol设置更改为crlf，，即使您已经为所有文件设置了text=auto一样. (如果将core.autocrlf设置为input会发生什么情况，需要仔细测试.)

Hence, since core.autocrlf can change the effective core.eol setting, and you can neglect to set a specific setting for some text file, having core.autocrlf set can be like changing your core.eol setting to crlf, even if you do already have text=auto set for all files. (What precisely happens if you set core.autocrlf to input would require careful testing.)

¹ 单词通常出现在这里，因为这是关于文件在Git进出中转换的位置.但是，对于某些操作，例如针对工作树的git diff或启用了规范化"的git merge，Git必须在在这种情况下，Git会进行一些额外的转换.不幸的是，这是为什么为什么 Git中的实际代码是如此曲折.

¹The word normally is here because this talks about where files get converted on the way in and out of Git. For some operations, though, such as git diff against a work-tree, or git merge with "normalization" enabled, Git must do a "virtual check-in" or "virtual check-in and check-out", in which case Git does some extra converting. This is, unfortunately, why the actual code inside Git is so terribly twisty.

这篇关于.gitattributes:text = auto是否仍使用core.autocrlf来检测EOL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！