75

我不明白 git: 中与 CrLf 设置相关的复杂性core.autocrlf：core.safecrlf

我正在一个团队中开发一个跨平台项目，并希望 Windows 和 Linux 开发人员能够一起工作，而无需 git 将文件标记为仅因为行结束样式而被修改。

各种设置是什么意思？选择任何选项会有什么后果？对于我的情况，最好的解决方案是什么？

是的，我知道这个问题，并且那里的答案没有洞察力，因此没有帮助。

4

3 回答 3

100

的三个值autocrlf：

  • true- 当内容进入存储库（已提交）时，其行尾将转换为 LF，当内容从存储库出来（已签出）时，行尾将转换为 CRLF。这通常适用于无知的 Windows 用户/编辑器。假设编辑器（或用户）将创建带有 CRLF 结尾的文件，并且如果看到正常的 LF 结尾会吓坏，但是您希望在 repo 中使用 LF 结尾，这有望涵盖您。不过，事情可能会出错。链接问题中有虚假合并冲突的示例和修改文件的报告。

  • input- 当内容进入存储库时，其行尾将被转换为 LF，但内容在输出时保持不变。这与 基本处于同一领域true，假设编辑器实际上可以正确处理 LF 结尾；您只是在防止意外创建带有 CRLF 结尾的文件的可能性。

  • false- git 根本不处理行尾。由你决定。这是很多人推荐的。使用此设置，如果文件的行尾将被弄乱，您必须意识到这一点，因此合并冲突的可能性要小得多（假设知情用户）。教育开发人员如何使用他们的编辑器/IDE 几乎可以解决这个问题。如果配置正确，我见过的所有为程序员设计的编辑器都能够处理这个问题。

请注意，这autocrlf不会影响已在存储库中的内容。如果您之前已经提交了带有 CRLF 结尾的内容，他们将保持这种状态。这是避免依赖 autocrlf 的一个很好的理由；如果一个用户没有设置它，他们可以将带有 CRLF 结尾的内容放入 repo，它会一直存在。强制规范化的一种更强大的方法是使用text 属性；auto假设 git 确定内容是文本（不是二进制），将其设置为给定路径将标记它以进行行尾规范化。

一个相关的选项是safecrlf，这基本上只是一种确保您不会对二进制文件进行不可逆转的 CRLF 转换的方法。

我在处理 Windows 问题和 git 方面没有大量经验，因此当然欢迎提供有关影响/陷阱的反馈。

于 2010-11-15T07:38:21.603 回答
12

我探索了提交和签出案例的 3 个可能值，这是结果表：

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

我建议core.autocrlf = input在所有平台上使用。在这种情况下，如果 Git 面对CRLF，它会隐式地将其转换为LF, 并且现有文件LF保持原样。

于 2016-12-22T11:48:34.543 回答
4

仅供参考，默认情况下，以 Windows 结尾的行将采用 CRLF，Linux 将采用 LF。请参阅下表以便清楚了解。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

在上面的表格信息中，符号 * 突出显示了 Windows 和 Unix 之间的差异。一目了然，以下是基于 OS 平台的 CLRF 信息：

对于 Windows 用户

  • 如果 windows 用户使用跨平台项目，它必须适用于core.autocrlf=trueWindows 机器和core.autocrlf=inputUnix 机器。
  • 如果 windows 用户只使用 windows 项目，它可以是两者core.autocrlf=true或core.autocrlf=false. 但是core.autocrlf=input在这种情况下会导致问题。

适用于 Unix 用户（Linux / Mac OS）

  • 如果 Unix 用户使用跨平台项目，它必须适用于core.autocrlf=trueWindows 机器和core.autocrlf=inputUnix 机器。
  • 如果 Unix 用户只使用 Unix 项目，它可以是两者core.autocrlf=input或core.autocrlf=false. 但是core.autocrlf=true在这种情况下会导致问题。

对于相同的操作系统用户

  • 对于纯 Windows 项目或纯 Unix 项目，它可以是core.autocrlf=false.
于 2017-07-03T22:12:34.240 回答