46

我每天都使用 Windows、Mac OS X 和 linux。我在所有这些环境中都使用 git，从那些对行尾有不同选择的人使用的 repos 中提取。

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

4

3 回答 3

35

正如我在这个SO question中所做的那样，我建议将其设置为 false。

如果您可以避免修改任何 eol（使用您的编辑器），那么最好在这些 eol 不变的情况下推迟您的工作（即“当您找到它们时”）。

于 2010-01-06T22:24:45.097 回答
17

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

于 2011-12-09T18:06:18.797 回答
13

对于具有相同文本但二进制表示中的不同行尾（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 & Whitespace Correction commit”，你会没事的（加上新用户的培训再培训）

您还可以确保您（每个用户）使用通用的空白调整设置，以便制表符 v 空格和尾随空格不会造成更多diff不便！

于 2011-05-15T11:54:42.663 回答