7
行尾转换如何在不同操作系统之间与git core.autocrlf一起使用
我已经阅读了关于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值 真输入假 -------------------------------------------------- -------- 提交| 兑换 ?? 新 转换为LF(转换为LF?)(不转换?) 提交| 转换成 ?没有 现有 LF(转换为LF?)转换 结帐| 转换成 ?没有 现有 CRLF(无转换?)转换 我并不是真的在寻求有关各种设置的优缺点的意见。我只是在寻找可以使git如何在这三个设置中运行的数据清楚。 - 更新04/17/2012:在阅读了 JJD链接的Tim Clem的文章后,我修改了上表中“未知”值中的某些值,以及更改了“ checkout existing | true”以进行转换而不是转换为客户端”。这是他给出的定义,这些定义比我在其他地方看到的任何定义都更清楚: core.autocrlf =假 这是默认设置,但建议大多数人立即更改此设置。使用false的结果是Git永远不会弄乱文件的行尾。您可以使用LF或CRLF或CR或这三者的某种随机组合来检入文件,而Git不在乎。这会使差异变得难以阅读,合并变得更加困难。在Unix / Linux世界中工作的大多数人都使用此值,因为他们没有CRLF问题,并且无论何时将文件写入对象数据库或写入工作目录中,都不需要Git进行额外的工作。 core.autocrlf =真 这意味着Git将处理所有文本文件,并确保在将文件写入对象数据库时将CRLF替换为LF,并在写入工作目录时将所有LF转换回CRLF。这是Windows上的建议设置,因为它可以确保您的存储库可以在其他平台上使用,同时将CRLF保留在工作目录中。 core.autocrlf …
220
git
newline
core.autocrlf