对git autocrlf设置的明确建议

Question

我每天都使用Windows,Mac OS X和Linux.我在所有这些环境中使用git,从具有不同选择的人们使用的repos中提取行结尾.

在我的情况下是否有建立core.autocrlf的明确建议？

Answer 1

正如我在这个问题中所做的那样,我建议将其设置为假.

如果你可以避免修改任何eol(使用你的编辑器),那么最好用那些没有改变的eol(即"你发现它们")推回你的工作.

Answer 2

在这些讨论中经常没有提到的一个问题是:如果你在Windows上开发shell脚本(例如,在cygwin中)并使用CRLF(autocrlf = false)提交它们,它们将在*nix框上崩溃并出现无用的错误消息.(其他脚本语言可能也有类似的情况.)在半个小时后,你会记住,然后dos2unix这些小流氓.如果您在混合环境中工作(例如从Windows部署到Linux服务器)并且您绝对想将autocrlf设置为false,那么请确保所有Windows编辑器都使用unix(lf)行结尾.否则设置autocrlf输入(和祈祷).大多数21世纪Windows程序在没有1980年代早期的行式打印机CR的情况下都很舒服,因此最好将行结束设置为LF(unix).

Answer 3

对于具有相同文本但在二进制表示内部具有不同的行尾(EOL)机制的两个文本文件,GIT不会有共同的SHA1 .内容存储为blob,如果将另一个相同的副本解放到re-pository中,则可以重复使用该内容(节省空间!)

()GIT(设计者)采用的默认选择是尽可能使用*nix样式的EOL字符(仅限LF),这样对于相同的文本内容,您将获得相同的SHA1.(可能是一个重要的考虑因素;-)

因为内容/ blob不再记住用户的原始EOL选择(记住它现在可能存在于某个远程存储库中),Git必须对如何重新创建原始用户的文件进行一些猜测(基于选项)(是CRLF还是仅仅是LF)以您(和您的工具)可以使用的方式.

通常的建议是本地每个用户(a)在提交到blob时转换为*nix LF结尾(因此所有人都会看到常见的SHA1 blob名称)(a/k/a the Right Thing),以及(b)本地设置本地系统设置的重新创建选项,例如*nix(LF)或Windows(CRLF)等.

为您的用户设置一些本地标准,并拥有一个大的'EOL/LF/CRLF和空白更正提交',你会没事(再加上新用户的培训再培训)

您还可以确保您(每个用户)使用常见的空白区域调整设置,以便标签v空格和尾随空格不会造成更多diff不便!