我在 Stack Overflow 上读到了很多关于 git 文档中 core.autocrlf 设置如何工作的不同问题和答案。
这是我从阅读中得到的理解:
Unix 和 Mac OSX(pre-OSX 使用 CR)客户端使用 LF 行尾。
Windows 客户端使用 CRLF 行尾。
当客户端将 core.autocrlf 设置为 true 时,git 存储文件始终采用 LF 行尾格式,并且对于使用非 LF 行尾(如 Windows)的客户端,在检出 / 提交时,客户端中的文件行尾会来回转换,无论客户端中的行尾格式是什么(这与 Tim Clem 的定义不符 - 请参见下面的更新)。
以下是一个矩阵,尝试记录 core.autocrlf 的“input”和“false”设置的相同内容,并在不确定行尾转换行为时带有问号。
我的问题是:
- 问号应该填什么?
- 这个矩阵对于“非问号”是否正确?
随着共识形成,我将从答案中更新问号。
core.autocrlf value true input false ---------------------------------------------------------- commit | 转换为 LF ? ? new | (转换为 LF?) (不转换) (不转换)
commit | 转换为 LF ? 不转换 existing | (转换为 LF?) 转换
checkout | 转换为 CRLF ? 不转换 existing | (不转换) 转换
我并不是真的在寻求关于各种设置的利弊的意见。我只是在寻找能够清晰说明git在每个设定下如何运作的数据。
--
更新于2012年04月17日:在评论中由JJD提供的Tim Clem的文章之后,我修改了上表中"unknown"值,并将"checkout existing | true"更改为转换为CRLF而不是转换为客户端。以下是他给出的定义,比我在其他地方看到的任何内容都更清晰:
core.autocrlf = false
这是默认设置,但大多数人被鼓励立即更改此设置。使用false的结果是Git永远不会处理文件的行尾。您可以检入带有LF或CRLF或CR或这三者的某些随机组合的文件,Git不会在意。这可能使差异更难以阅读,合并更加困难。大多数在Unix / Linux世界中工作的人使用此值,因为他们没有CRLF问题,也不需要Git在将文件写入对象数据库或写入工作目录时进行额外的工作。
core.autocrlf = true
这意味着Git将处理所有文本文件,并确保在将该文件写入对象数据库时将CRLF替换为LF,并在写入工作目录时将所有LF转换回CRLF。这是Windows上推荐的设置,因为它确保您的存储库可以在其他平台上使用,同时保留工作目录中的CRLF。
core.autocrlf = input
这意味着Git将处理所有文本文件,并确保在将该文件写入对象数据库时CRLF被替换为LF。但是,它不会执行相反的操作。当您从对象数据库中读取文件并将其写入工作目录时,它们仍将具有LF以表示行尾。通常在Unix/Linux/OS X上使用此设置,以防止将CRLFs写入存储库。其想法是,如果您从Web浏览器复制代码并意外地将CRLFs插入到其中一个文件中,Git将确保在写入对象数据库时将其替换为LF。蒂姆的文章很好,我能想到唯一缺少的是他假设存储库采用LF格式,这不一定正确,特别是对于仅限Windows的项目。将蒂姆的文章与jmlane迄今为止最高投票的answer进行比较,可以在真实和输入设置方面达成完全一致,但在错误设置方面存在分歧。
autocrlf
为false似乎更加简单 ;) https://dev59.com/unE95IYBdhLWcg3wY85l#2354278 - VonC