git autocrlf设置的权威性建议

Question

我每天使用Windows，Mac OS X和linux。我在所有这些环境中都使用git，它是从回购中提取出来的，回购是人们对行尾使用不同选择的。在我的情况下是否有确定设置core.autocrlf的建议？

Answer 1

将其设置为false。

如果您可以避免使用编辑器修改任何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，如果将另一个相同的副本存储到存储库中，则将重复使用该内容（节省空间！）

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不便！