Adr*_*ski 2 git settings line-endings
有人可以解释一下设置之间的区别吗：
core.autocrlf = true
core.eol = native
和
core.autocrlf = input
当我们同时使用两种情况？
什么时候我们应该使用[这两个设置]？
我的喜好从来没有。另一方面，我也不在Windows上工作。:-)但是，如果您仔细阅读下面的所有内容，将会发现如果我这样做了，我仍然会说“从不”。（即使您共享一些不允许在其中创建.gitattributes文件的上游存储库，也可以$GIT_DIR/info/attributes在自己的克隆中使用每个存储库文件。）
[有什么不同？]
要获得差异，我们需要首先注意：
第一部分非常简单，尽管它为新手提供了自己的绊脚石。Git可以进行任何所需的转换，因为它具有Git所谓的clean filter和smudge filter。
一个干净的过滤器是一个转换你，是的，你！你自己-能写，当你从工作树的文件复制到使用索引的Git将应用git add或同等学历。也就是说，假设您有一个文件检入到工作树中，然后对其进行编辑或完全替换，或者在该文件上运行某些程序对其进行更改。您可能要提交该文件的新版本。因此，您必须运行将文件从工作树复制回索引。（请记住，Git是根据索引中的内容而不是工作树中的内容进行新提交的。这就是为什么您一直都必须对文件进行提交的原因：Git不会自动从工作树中复制到索引中。）git add pathgit add
每当您运行时，Git都会在输入过程中 “清除”文件。这就是输入转换。git add file
相反，您可以编写自己的污迹过滤器，当从 Git发出数据（从索引到工作树）时，可以对数据进行归档。由于Git内部的所有文件，包括准备复制到下一次提交的索引中的文件，都采用某些特殊的，内部的，仅Git的格式，因此每个文件都必须转换为所有普通计算机都可以使用的普通格式。程序可以处理。每当您将文件提取到工作树时，Git都会在出局时“涂抹”（脏污）文件。那是一个输出转换。
Git会偶尔做一个输入转换而无需实际复制该文件到索引：特别是，如果你运行git diff的是比较一个工作树文件索引或同一文件的提交副本，一个最里面的档案库有已经被“清理”了，而工作树中的全部“被弄脏了”和“脏了”。在它们都处于相同状态之前，无法对其进行比较，因此Git将在进行比较之前“清理”工作树。
Git有两个内置的转换。一种是在清理时使用的，即当文件从工作树复制到Git（进入索引）时使用。这一行将CRLF行尾替换为仅换行符，Linux风格的行尾。另一种是在涂抹时使用，即从Git复制文件时使用。此其替换换行符只能用......嗯，Linux样式行尾的东西。
可以用这种“东西” core.eol来实现。您可以让Git用CRLF替换换行符，如果您使用的是Windows，并且您有要求这些行以CRLF结尾的程序，则可能需要用它，但是您也正在与工作人员一起在Linux上，要求行以仅LF换行符结尾。
或者，您可以让Git用仅LF替换换行符...但这不是替代，因为换行符是换行符“ LF”。称其为替代品有点愚蠢。
您可以让Git根据您的系统选择结尾，以便将core.eol设置为的一种配置native在Linux 和 Windows 上均可使用。
Git有点偷偷摸摸：当要用LF“替换” LF（毕竟这不是替代品）时，它往往无能为力-甚至不检查任何东西-因此运行得更快。似乎您可能永远不会注意到这一点，只是该core.safecrlf设置要求Git检查事物。这safecrlf件事涉及一些猜测，它意味着过度保护，.gitattributes如果您要进行转换，则可以让您设置设置，这样就不会损坏任何二进制文件。
一些文件，如.jpg例如图像，只是没有文字，应该永远不会有任何的“文本十岁上下”的方式修改他们的数据。它们需要使用图像处理代码来操纵，而不是使用文本编辑器或笨拙的工具行Git的内置转换来操纵。因此，Git需要一种区分文本文件和非文本文件或二进制文件的方法，文本文件应应用这些行尾转换。
如果您不告诉Git哪些文件，那将不得不猜测。Git用来猜测的方法是不查看.jpg或.txt扩展名-例如，这不适README用于名为的文件。取而代之的是，Git查看存储在文件中的数据，并根据它是“看起来像文本的”还是“看起来像二进制的”进行猜测。
可以想象，这个猜谜游戏并不完美。它可能对您有用，但如果不起作用，您可以并且应该告诉 Git哪些文件。您可以通过创建一个名为的文件来实现.gitattributes。在中.gitattributes，您可以将特定的文件名（例如README）或路径名模式（例如*.txt和）列出*.jpg为“绝对文本”或“绝对二进制”。您可以使用text或进行此操作-text。您还可以告诉Git：猜猜！ 您可以这样操作auto：
*.txt text
*.jpg -text
guess auto
auto如果可以帮助，则永远不要使用。
如果您从未让Git进行任何转换，则不必这样做。 告诉Git哪些文件是文本文件，哪些是二进制文件，是为了确保Git正确执行了转换，并且只有在进行转换时才需要这样做。因此，如果您避开Windows，则无需创建.gitattributes和列出文件。无论如何创建它并没有真正的伤害，但是如果您创建了它，则应该尝试使其覆盖所有文件，这样Git不必猜测。
考虑到以上内容，我们可以core.autocrlf通过参考git config文档并向下滚动至core.autocrlf说明来了解其作用：
将此变量设置为“ true”与将
text所有文件的属性设置为“ auto”以及将core.eol设置为“ crlf”相同。如果要CRLF在工作目录中有行尾并且存储库中有LF行尾，请设置为true 。可以将此变量设置为input，在这种情况下，不执行输出转换。
换句话说，core.autocrlf=true就像auto在所有文件上使用该设置一样，这是您永远都不应做的事情。因此，您永远不要使用此功能。:-)它可以工作，但我不建议这样做：创建一个适当.gitattributes的文件并在其中列出所有文件，以免您玩猜谜游戏。 一旦你的.gitattributes文件列表的一切，core.autocrlf=true没有任何效果，因为.gitattributes设置将其覆盖。
using core.autocrlf=input告诉Git进行相同的猜测，但也仅进行输入转换（git add例如在清洁过程中）。我本人对此设置没有用，也无法真正想象出任何一个好主意的情况。可能存在这种情况，但是如果您要进行转换，则应明确指定它们；并且在.gitattributes文件中正确指定了它们之后，双向进行转换似乎更有意义，因此无需使用input。
至于设置core.eol为native，文档声称这是默认设置（似乎是最好的选择），因此除了覆盖其他配置文件对非默认设置的错误选择外，没有其他理由打扰。