git autocrlf设置的权威性建议

我每天使用Windows,Mac OS X和linux。我在所有这些环境中都使用git,它是从回购中提取出来的,回购是人们对行尾使用不同选择的。

在我的情况下是否有确定设置core.autocrlf的建议?


牧羊人nacy
浏览 529回答 3
3回答

FFIVE

将其设置为false。如果您可以避免使用编辑器修改任何eol,那么最好以不变的eol(即“如您所见”)将您的工作推迟。

慕容森

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

森栏

对于二进制文本表示形式中具有相同文本但行尾(EOL)机制不同的两个文本文件,GIT不会具有通用的SHA1 。内容存储为Blob,如果将另一个相同的副本存储到存储库中,则将重复使用该内容(节省空间!)GIT(设计者)的默认选择是尽可能使用* nix样式的EOL字符(仅LF),以便对于相同的文本内容,您具有相同的SHA1。(可能是重要的考虑因素;-)因为内容/ blob不再记住用户的原始EOL选择(记住现在可能在某个遥远的存储库中),所以Git必须对如何重新创建原始用户的文件(是CRLF还是简单地)做出一些猜测(基于选项)。 LF)以您(和您的工具)可以使用的方式使用。通常的建议是,每个用户在本地(a)提交到Blob时都转换为* nix LF结尾(因此所有人都会看到通用的SHA1 Blob名称)(a / k / a Right Thing),而(b)在本地设置重新创建其本地系统设置的选项,例如* nix(LF)或Windows(CRLF)等。为您的用户设置一些本地标准,并进行一次大的“ EOL / LF / CRLF和空格校正提交”,就可以了(加上对新用户的培训再培训)您还可以确保您(每个用户)使用通用的空格调整设置,以使制表符v空格和结尾的空格不会造成更多的diff不便!
打开App,查看更多内容
随时随地看视频慕课网APP