行尾行为和 Git答案

【问题标题】：End-of-Line Behavior and Git行尾行为和 Git
【发布时间】：2020-08-14 06:59:03
【问题描述】：

我是 Git 新手。我之前使用过 GitHub，但最近我开始在我的系统上本地使用 Git 本身进行版本控制。

我在 Windows 系统上。但是，我正在处理最初在 Mac 上创建的一些文件。因此，每当我暂存文件时，都会收到以下警告：

警告：在contact.html 中LF 将被CRLF 替换。该文件将在您的工作目录中以原始行结尾

现在，我在此主题上发现的每个先前问题本质上只是一群人一遍又一遍地解释设置 (core.autocrlf = true) 的目的。手册页非常清楚，在 Windows 系统上，“true”应该导致工作目录中的 CRLF，但所有提交都将在 repo 中转换为 LF。我明白了。

1) 为什么这条消息的措辞如此糟糕。听起来倒退了。最初的行尾（至少最初）是 LF。那不应该在我的工作目录中。听起来好像它向我保证它将在工作目录中保留 LF，但在 repo 中是 CRLF。与我想要的相反。

2）假设'core.autocrlf=true'给了我我想要的行为（回购中的LF----工作副本中的CRLF）。如何禁用这个非常混乱的消息，以便每次“git add”时都看不到它？如果我正在处理多个文件，它会造成很多视觉混乱。

【问题讨论】：

对于它的价值，我认为警告中的文字本身也很差。确实，Git 应该打印一条警告消息，告诉您往返数据可能会导致某种数据丢失，并包含指向网页的链接，其中包含（长！）描述如何往返工作，每个数据更改都可能发生。它应该包括关于如何配置 Git、从哪里获取以及如何运行 Git 应该附带的诊断工具的说明（但在未来的某个版本之前不会也不会）。
不过，最终，整个事情都充满了麻烦：现有 Git 版本和现有存储库无法修复。只有未来的 Git 版本和新的提交才能在需要时进行更正。

标签： windows git end-of-line

【解决方案1】：

此消息表示您的工作树中有文件以 LF 结尾。这是有道理的，因为它们是在 Mac 上创建的，并且所有现代版本的 macOS 都使用 LF 结尾。但是，如果您提交它们然后检查它们，您将得到 CRLF 行结尾，因为您在 Windows 上并且设置了 core.autocrlf。这就是消息的意思。下次出于任何原因签出文件时，工作树中的 LF 结尾将被替换。

这个想法，至少在原则上，是为了警告你，你的行尾不会被保留，以防万一对你很重要。也许您正在使用 shell 脚本，即使在 Windows 上，shell 也需要 LF 结尾。因此，您需要向.gitattributes 添加一个条目。

如果您使用二进制文件执行某些行结束转换会导致损坏的操作，它还有助于警告您。毕竟，如果您更改所有 0x0a 和 0x0d 字节，您的精美 JPEG 图像将无法正常工作。

如果需要，您可以通过将 core.safecrlf 设置为 false 来关闭此警告。

【讨论】：