我在Stack Overflow上阅读了很多不同的问题和答案,以及关于core.autocrlf设置如何工作的git文档.
这是我对以下内容的理解:
Unix和Mac OSX(OSX之前使用CR)客户端使用LF行结尾.
Windows客户端使用CRLF行结尾.
当在客户端上将core.autocrlf设置为true时,git存储库始终以LF行结束格式存储文件,并且客户端(即Windows)在签出/提交时来回转换客户端文件中的行结尾-LF行结尾,无论行结尾文件在客户端上的格式是什么(这与Tim Clem的定义不一致 - 请参阅下面的更新).
这是一个矩阵,试图为带有问号的core.autocrlf的'input'和'false'设置记录相同的内容,我不确定行结束转换行为.
我的问题是:
我将从答案中更新问号,因为似乎已形成共识.
core.autocrlf value
true input false
----------------------------------------------------------
commit | convert ? ?
new | to LF (convert to LF?) (no conversion?)
commit | convert to ? no
existing | LF (convert to LF?) conversion
checkout | convert to ? no
existing | CRLF (no conversion?) conversion
我并不是真的在寻找各种设置的利弊意见.我只是在寻找数据,这清楚地说明了如何期望git能够在三种设置中运行.
-
2012年4月17日更新:阅读了由JJD在评论中链接的Tim Clem的文章后,我修改了上表中"未知"值中的一些值,并更改了"checkout existing | true to conversion"到CRLF而不是转换为客户".以下是他给出的定义,这些定义比我在其他地方看到的更清楚:
core.autocrlf …
我克隆了一个存在不一致行结尾的存储库.我添加了一个.gitattributes为我想要规范化的文件设置text属性.现在,当我提交更改时,我收到消息:
warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.
如何让git为我标准化我的文件的工作副本？我希望git能够规范化整个工作树.
在与使用不同操作系统的人一起工作时，由于行结束，我遇到了合并冲突问题。我在 Windows 上工作，我的同事在 Mac 上工作。当他推送他的更改时，有时他没有处理过的文件会在 diff 中显示为已更改，因为现在^M每个文件上都会显示行尾。这导致了合并冲突。我在 Git 文档中阅读了以下内容：
当您将文件添加到索引时，Git 可以通过将 CRLF 行结尾自动转换为 LF 来处理此问题，反之亦然，当它检出代码到您的文件系统时。您可以使用 core.autocrlf 设置打开此功能。如果您使用的是 Windows 计算机，请将其设置为 true？—？这会在您检出代码时将 LF 结尾转换为 CRLF：
$ git config --global core.autocrlf true 如果你在使用 LF 行尾的 Linux 或 macOS 系统上，那么你不希望 Git 在检出文件时自动转换它们；但是，如果意外引入了带有 CRLF 结尾的文件，那么您可能需要 Git 修复它。您可以通过将 core.autocrlf 设置为输入来告诉 Git 在提交时将 CRLF 转换为 LF，而不是相反：
$ git config --global core.autocrlf input 这个设置应该让你在 Windows 结账中使用 CRLF 结尾，但在 macOS 和 Linux 系统以及存储库中使用 LF 结尾。
这是有道理的，但我仍然不清楚这些文件是如何在 repo 中实际提交的。例如，如果他在他的系统上创建一个文件，它会有所有的LF行结尾，对吗？因此，当他提交时，我认为这些行结尾保持原样。据我所知，当我拉动时，我的autocrlf存在true会用CRLF行尾检查它们。（我收到警告warning: …