git - autocrlf和eol有什么区别

Question

我正在阅读关于.gitattributes的git documentation来解决混合线端点的问题，并发现有两个类似的设置。
自动RLF：
行尾转换，而git通常只保留文件内容，
它可以配置为规范化存储库中lf的行尾。
并且，还可以选择在文件签出时将它们转换为CRLF。
如果您只想在工作目录中有crlf行尾
无论您使用的是哪个存储库，都可以设置
不使用任何属性的配置变量“core.autocrlf”。
[core]autocrlf=true这不会强制文本规范化
文件，但确实确保
存储库的行尾在
添加了，并且存储库中已规范化的文件
保持正常。
下线：
此属性设置要在
工作目录。它可以在没有任何
内容检查，有效设置文本属性。
设置为字符串值“crlf”此设置强制git规范化行
签入时此文件的结尾，并在
文件已签出。
设置为字符串值“lf”此设置强制git规范化行
在签入时结束到lf，并防止在文件
已签出。
向后兼容crlf属性
为了向后兼容，crlf属性解释如下：
CRLF文本
-CRLF-文本
CRLF=输入下线=LF
似乎两者都在做同样的事情，但是有一些关于compatibility。这是否意味着autocrlf已被弃用，而新口味是eol或其他什么？我目前有一个包含多个损坏文件的存储库，我想将其转换为crlf表示形式。你也看到那些文件把我们搞糊涂了，而不是把事情弄清楚了。
在这种情况下我应该申请什么？

Answer 1

与其直接回答问题本身，不如查看链接问题的VonC's answer，让我们集中精力：
我现在有一个包含多个损坏文件的存储库，我想将其转换为CRLF表示。
首先，请注意，这些选项中没有一个可以更改任何现有提交。这是一个基本的Git属性：一旦创建，就不能更改现有的提交。你能做的就是做出新的承诺。这通常不是什么大问题，因为我们通常只希望新内容是正确的（请参见git filter-branch，它在对其内容应用筛选器后复制提交，并可用于重新复制整个存储库：新的repo不再与旧的repo兼容，但您可以通过这种方式“修复历史记录”）。
接下来，我认为这是理解所有这些行尾/crlf属性选项的关键：当文件移入或移出索引时，转换将应用于文件。
记住git的索引是构建下一个提交的地方。索引的内容最初与当前提交的内容相同：例如，您运行git checkout master，git将名称master解析为提交id，并将该特定提交复制到您的工作树中，但副本会通过索引。
换句话说，git首先发现文件foo.txt在提交中（需要提取）。因此git将foo.txt的版本移动到索引。索引的版本与commmit的版本完全匹配。Git不会对索引版本应用任何筛选器，也不会更改任何行尾。
一旦更新了索引版本，git就会将该版本的文件从索引复制到工作树。1在提取过程中，现在会进行一些转换。如果有污迹过滤器，git现在就应用它。如果要进行行尾转换，git现在就应用这些转换。
在此过程中，工作树文件可能与索引版本不同。现在git有一个问题，因为现在文件是“脏的”（在工作树中修改）。这就是事情变得特别混乱的地方，尽管大多数时候，这里的细节是看不见的。
最后，在使用工作树之后，您可以在某些文件路径名上运行HEAD（或者使用git add或其他方式添加许多文件）。这会将文件从工作树复制到索引中。在复制过程中，现在还会发生2个转换：如果有一个干净的过滤器，git会立即应用它。如果要进行行尾转换，git现在就应用它们。
换句话说，在处理这些文件之后，索引版本可能与工作树版本不匹配。但是，git仍然将索引版本标记为“匹配”。agit add -a将跳过工作树版本，因为git现在声明索引版本与工作树版本匹配。这有点像，因为索引版本与再次运行git add时要添加的内容相匹配。
实际的实现使用时间戳，通常只有一秒钟的分辨率。Git将继续相信索引版本与工作树版本匹配，除非并且直到操作系统触及文件的工作树版本的时间戳。即使更改要应用的筛选器集和/或行尾转换，也会出现这种情况。git并没有意识到您已经改变了行结尾的工作方式，或者更改了“clean”过滤器来做一些不同的事情：它只是看到索引的“cache”部分显示“i match work tree version time stamp t”。只要工作树版本的时间戳仍然是t，文件就必须是“干净的”。
因此，要在更改任何文本转换设置后更新这些内容，您需要让git意识到文件不干净。您可以git status将新的时间戳设置为“now”，这与索引中较旧的时间戳不匹配。现在git add（或其他）将像往常一样扫描，但是由于时间戳不匹配，它这次将找到文件，并将重新筛选它以将其添加到索引中。
同样，当您touch <path>文件时，会发生这些转换。
通常，在类似windows的系统中，您的目标是获取lf-only存储库格式的文件，并将它们转换为cr-lf文件，供windows处理。这种转换发生在离开索引到工作树的过程中：即在git add -a期间。然后您需要在git add过程中将这些cr-lf工作树文件转换为lf-only格式，这样，in-repository格式就是linux（和linus torvalds，因此git:-）喜欢它们的方式。但如果您真的想惹恼所有unix/linux用户，可以将它们以cr-lf格式存储在存储库中。这都是一个转换的问题，如果有的话，你可以在哪个步骤应用：git checkout时间，和git add时间。
git checkout文件指定要应用于哪些文件的转换。git add和.gitattributes设置没有：git必须对哪些文件在哪个步骤得到哪些转换做出最佳猜测。
1技术上，索引中的所有内容都是文件的哈希ID。文件本身作为git blob对象存储在存储库数据库中。正如commit对象一样，这些blob对象是不可变的。这就是为什么不能在索引中更改它：它实际上只是一个散列ID。
2core.autocrlf进程只需编写一个新blob，并在任何筛选之后写入新blob。如果新的BLB完全匹配一些现有的BLB，一点一点，新的BLUB重新使用现有的BLUB的数据库条目和散列ID，并且实际上不保存现有的BLUB足够。否则，blob的数据将存储为一个新文件，并带有一个新的id。进入索引的是新的散列id。