377

我有一个可以从 Windows 和 OS X 访问的 Git 存储库，并且我知道它已经包含一些带有 CRLF 行结尾的文件。据我所知，有两种方法可以解决这个问题：

  1. 无处不core.autocrlf在false，

  2. 按照此处的说明（在 GitHub 的帮助页面上回显）将存储库转换为仅包含 LF 行尾，然后在 Windows 和OS X 上设置core.autocrlf为。这样做的问题是，如果我在存储库中有任何二进制文件那：trueinput

    1. 在 gitattributes 中未正确标记为二进制，并且
    2. 碰巧同时包含 CRLF 和 LF，

    他们将被破坏。我的存储库可能包含此类文件。

那么为什么我不应该关闭 Git 的行尾转换呢？网络上有很多关于core.autocrlf关机导致问题的模糊警告，但很少有具体的警告；到目前为止，我唯一发现的是 kdiff3 无法处理 CRLF 结尾（对我来说不是问题），并且某些文本编辑器存在行尾问题（对我来说也不是问题）。

该存储库是我公司内部的，因此我无需担心与具有不同 autocrlf 设置或行尾要求的人共享它。

只保留我不知道的行尾是否还有其他问题？

4

6 回答 6

290

autocrlf设置为的唯一具体原因true是：

  • 避免git status显示所有文件，modified因为在将基于 Unix 的 EOL Git 存储库克隆到 Windows 时完成了自动 EOL 转换（例如，参见问题 83）
  • 并且您的编码工具以某种方式取决于文件中存在的本机EOL 样式：

除非您可以看到必须处理本地 EOL 的特定处理，否则您最好离开autocrlf(false ) git config --global core.autocrlf false。

请注意，此配置将是本地配置（因为配置不会从仓库推送到仓库）

如果您希望克隆该存储库的所有用户使用相同的配置，请使用文件中的属性查看“使用 git的最佳CRLF处理策略是什么？ ” 。text.gitattributes

例子：

*.vcproj    text eol=crlf
*.sh        text eol=lf

注意：从 git 2.8（2016 年 3 月）开始，合并标记将不再在 CRLF 文件中引入混合行尾（LF）。
请参阅“让 Git 在其“<<<<<<< HEAD”合并行上使用 CRLF ”

于 2010-05-13T09:55:15.093 回答
54

我是一名 .NET 开发人员，多年来一直使用 Git 和 Visual Studio。我强烈建议将行尾设置为 true。并在存储库的生命周期内尽可能早地执行此操作。

话虽如此，我讨厌 Git 改变我的行尾。源代码管理应该只保存和检索我所做的工作，它不应该修改它。曾经。但确实如此。

如果您没有将每个开发人员都设置为 true，将会发生什么，一个开发人员最终将设置为 true。这将开始将您所有文件的行尾更改为 LF 在您的存储库中。当用户设置为 false 时，Visual Studio 会警告您，并要求您更改它们。您将很快发生两件事。一，你会得到越来越多的警告，你的团队越大，你得到的越多。第二个也是更糟糕的事情是，它会显示每个修改文件的每一行都已更改（因为每一行的行尾都会被真正的人更改）。最终，您将无法再可靠地跟踪存储库中的更改。让每个人都保持真实比试图让每个人都保持虚假要容易和干净得多。忍受你信任的源代码控制正在做它不应该做的事情的事实是多么可怕。曾经。

于 2016-06-10T13:23:32.680 回答
12

更新 2：

Xcode 9 似乎有一个“功能”，它将忽略文件的当前行结尾，而是在将行插入文件时使用默认的行结尾设置，从而导致文件具有混合行结尾。

我很确定 Xcode 7 中不存在这个错误。不确定 Xcode 8。好消息是它似乎已在 Xcode 10 中修复。

在它存在的时候，这个错误在我在问题中提到的代码库中引起了少量的欢闹（直到今天还在使用autocrlf=false），并导致了许​​多“EOL”提交消息，最终导致我编写了一个 git pre-commithook 来检查用于/防止引入混合行结尾。

更新：

注意：正如 VonC 所指出的，从 Git 2.8 开始，合并标记不会将Unix 风格的行尾引入 Windows 风格的文件。

原文：

我在此设置中注意到的一个小问题是，当存在合并冲突时，git 添加的用于标记差异的行没有Windows 行尾，即使文件的其余部分有，你也可以结束带有混合行结尾的文件，例如：

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

这不会给我们带来任何问题（我想任何可以处理这两种类型的行尾的工具也可以处理混合的行尾——当然是我们使用的所有工具），但这是需要注意的。

*我们发现的另一件事是，当git diff用于查看对具有 Windows 行尾的文件的更改时，已添加的行显示它们的回车符，因此：

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

* 它并不真正值得这个词：“问题”。

于 2012-01-16T16:50:00.750 回答
0

在我们的项目中，我们声明了将 autocrlf 设置为输入值的必要性。这就是您可能对此感兴趣的原因：

  • 您的项目在 Linux/Unix 环境中运行，开发人员正在 Windows 中编写代码。在推送期间，CRLF 会自动转换为 LF，因此您只需在 Unix 服务器上签出 Git repo，一切都会很好。
  • 有时，开发人员使用 WinSCP 手动将配置从 Windows 机器上传到服务器。这会导致 Unix 机器上的 CRLF 行结束和应用程序启动失败。“输入”值部分消除了此类情况的数量

我们不久前面临的问题：

  • 如果在 DEV 的机器上将行尾设置为 CR（而不是 CRLF），则在推送期间它们不会转换为 LF，并将在 GIT 存储库中保持 CR。彻底检查行尾
于 2021-12-13T11:57:38.727 回答
0

为了我。

编辑 .gitattributes 文件。

添加

*.dll binary

然后一切顺利。

于 2020-07-24T03:32:24.927 回答
0

我在 GitHub 上工作，我发现这篇文章很有帮助。

它描述了 git autocrlf 的配置和设置 .gitattributes 文件。

于 2021-05-27T03:52:11.003 回答