Windows git“警告：LF 将被 CRLF 取代”，那个警告尾巴是向后的吗？答案

【问题标题】：Windows git "warning: LF will be replaced by CRLF", is that warning tail backward?Windows git“警告：LF 将被 CRLF 取代”，那个警告尾巴是向后的吗？
【发布时间】：2013-07-11 18:52:43
【问题描述】：

环境：

Windows 7
msysgit

当我git commit时，它说：

warning: LF will be replaced by CRLF.

这个警告尾巴是向后的吗？
我在 Windows 中编辑文件，行尾是CRLF，就像这张图片：

并且 git 将其更改为 LF 以提交回购。
所以我认为正确的警告是：

warning: CRLF will be replaced by LF.

【问题讨论】：

另见stackoverflow.com/questions/1598260/make-crlf-warnings-go-away和stackoverflow.com/questions/5834014/…
@devnull 我的意思是警告是尾部向后，是吗？
@Honghe.Wu 不，它不在 Windows 上。我已经编辑了my answer below
很好的问题，因为确实，警告似乎是落后的。在 commit 上收到关于将 转换为 CRLF 的警告真的很令人困惑，而且再多解释 Git 对空格的处理也无济于事，因为警告是 backwards i>.
@user1460043 随意支持评论:) 但我认为事实的确认不值得回答。这只是 Git for Windows 中的一个错误。有人应该报告它（或者更好的是，修复它）

标签： git

【解决方案1】：

警告：LF 将被 CRLF 替换。

根据您使用的编辑器，带有 LF 的文本文件不必使用 CRLF 保存：最近的编辑器可以保留 eol 样式。但是那个 git config 设置坚持要改变那些......

只需确保（如I recommend here）：

git config --global core.autocrlf false

这样，您可以避免任何自动转换，并且仍然可以通过.gitattributes file 和core.eol directives 指定它们。

windows git "LF 将被 CRLF 替换"
这个警告尾巴是向后的吗？

不：你在 Windows 上，git config help page 确实提到了

如果您想在工作目录中使用 CRLF 行结尾，即使存储库没有标准化的行结尾，也可以使用此设置。

如“git replacing LF with CRLF”中所述，它应该只发生在结帐时（而不是提交），core.autocrlf=true。

       repo
    /        \ 
crlf->lf    lf->crlf 
 /              \

正如XiaoPeng 的answer 中所述，该警告与以下内容相同：

警告：（如果您使用当前core.autocrlf 配置签出/或克隆到另一个文件夹，）LF 将被CRLF 替换
该文件将在您的（当前）工作目录中具有其原始行尾。

如git-for-windows/git issue 1242中所述：

我仍然觉得这条消息令人困惑，可以扩展该消息以包含对该问题的更好解释，例如：“删除文件并再次检出后，file.json 中的 LF 将被替换为 CRLF”。

注意：Git 2.19（2018 年 9 月），在使用 core.autocrlf 时，伪造的“LF 将被 CRLF 替换”警告现在被抑制。

作为quaylar 正确的comments，如果在提交时有转换，则仅限于LF。

那个特定的警告“LF will be replaced by CRLF”来自convert.c#check_safe_crlf()：

if (checksafe == SAFE_CRLF_WARN)
  warning("LF will be replaced by CRLF in %s.
           The file will have its original line endings 
           in your working directory.", path);
else /* i.e. SAFE_CRLF_FAIL */
  die("LF would be replaced by CRLF in %s", path);

被convert.c#crlf_to_git()调用，自身被convert.c#convert_to_git()调用，自身被convert.c#renormalize_buffer()调用。

最后一个renormalize_buffer() 仅由merge-recursive.c#blob_unchanged() 调用。

所以我怀疑这种转换只发生在git commit 上，前提是所述提交是合并过程的一部分。

注意：对于 Git 2.17（2018 年第二季度），代码清理会增加一些解释。

见commit 8462ff4（2018 年 1 月 13 日）Torsten Bögershausen (tboegi)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 9bc89b1，2018 年 2 月 13 日）}

convert_to_git(): safe_crlf/checksafe 变成 int conv_flags

当调用convert_to_git()时，checksafe参数定义了什么如果 EOL 转换 (CRLF --> LF --> CRLF) 没有往返干净。
此外，它还定义了是否应重新规范化行尾 (CRLF --> LF) 或保持原样。

checksafe 是一个具有以下值的 safe_crlf 枚举：

SAFE_CRLF_FALSE:       do nothing in case of EOL roundtrip errors
SAFE_CRLF_FAIL:        die in case of EOL roundtrip errors
SAFE_CRLF_WARN:        print a warning in case of EOL roundtrip errors
SAFE_CRLF_RENORMALIZE: change CRLF to LF
SAFE_CRLF_KEEP_CRLF:   keep all line endings as they are

请注意，8462ff4 ("convert_to_git(): safe_crlf/checksafe 变为 int conv_flags", 2018-01-13, Git 2.17.0) 回到 Git 2.17 周期导致 autocrlf 重写以产生警告消息 尽管设置了safecrlf=false。

参见Anthony Sottile (asottile) 的commit 6cb0912（2018 年 6 月 4 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 8063ff9，2018 年 6 月 28 日）}

【讨论】：

是的，大多数编辑器都可以保留 EOL 样式，但是对于大多数编辑器，在同一个项目中创建新文件时没有效果。确保您没有签出 LF 项目，想“psh，我的编辑器可以处理 LF 行结尾，我不需要 autocrlf”，然后忘记手动将新文件设置为 LF 行结尾。
@VonC 我必须承认我没有得到它。 Git-Book 指出 Git 可以通过在您提交时将 CRLF 行结尾自动转换为 LF 来处理这个问题，反之亦然，当它检出代码到您的文件系统时。 这意味着在 commit 将转换为 LF 而永远不会转换为 CRLF。这意味着上述警告是不正确的。拥有core.autocrlf=true 将总是在 repo 中产生 LF，在工作树 imho 中产生 CRLF（即使在非 Windows 下）。来源：link
“这个警告尾巴向后吗？它应该只在结帐时出现” 我在 commit 上看到了这个确切的警告。所以是的，它是落后的。它向后触发了我寻找这个。很高兴其他人也注意到了！对于实际阅读这些警告的人来说，看到它说它将在提交消息上转换为 CRLF，这会让人非常困惑。
“所以我怀疑这种转换只发生在 git 提交上，前提是所述提交是合并过程的一部分。”没有。我在定期提交时看到了这一点。
这条消息让我烦恼的部分是它完全弹出。为什么我需要被警告 git 将完全按照我的配置去做。我不需要警告说“嘿，我们仍在为你转换行尾，就像你要求我们做的那样”。当系统按设计运行时，它不应该发出不必要的警告，否则人们会在不相关的消息海洋中错过重要的警告。

【解决方案2】：

在我设置core.autocrlf=true 之后，当我在git adding（或者可能是在git commit？ ) 在我设置core.autocrlf=true 之前签出的存储库（确实使用LF）上的Windows 中编辑的文件。

我使用core.autocrlf=true 进行了新的结帐，但现在我没有收到这些消息。

【讨论】：

【解决方案3】：

做简单的事：

打开 git-hub (Shell) 并导航到文件所属的目录 (cd /a/b/c/...)
执行dos2unix（有时是dos2unix.exe）
立即尝试提交。如果你再次遇到同样的错误。执行上述所有步骤，除了 dos2unix 之外，执行 unix2dox（有时是 unix2dos.exe）

【讨论】：

【解决方案4】：

YES警告是向后的。

事实上，它甚至不应该是一个警告。因为所有这些警告都在说（但不幸的是倒退）是文件中带有 Windows 行结尾的 CRLF 字符将在提交时被替换为 LF。这意味着它被标准化为 *nix 和 MacOS 使用的相同行尾。

没有发生什么奇怪的事情，这正是您通常想要的行为。

当前形式的警告是以下两种情况之一：

一个不幸的错误与过于谨慎的警告消息相结合，或
一个非常聪明的情节让你真正想通了......

;)

【讨论】：

奇怪的是，如果你强行将 Windows 上的本地文件转换为 LF，你甚至无法 git add 文件，消息会抱怨并使你的提交无效。

【解决方案5】：

所有这些都假设core.autocrlf=true

原来的错误：

警告：LF 将被 CRLF 替换
该文件将在您的工作目录中具有其原始行结尾。

错误应该是什么：

警告：LF 将被替换为 CRLF在您的工作目录中
该文件将在 git 存储库中具有其原始 LF 行结尾

解释here：

这种方便转换的副作用，也就是您所看到的警告，如果您最初创建的文本文件以 LF 结尾而不是 CRLF 结尾，它将像往常一样与 LF 一起存储，但是当稍后签出时，它将具有 CRLF 结尾。对于普通的文本文件，这通常很好。在这种情况下，警告是“供您参考”，但如果 git 错误地将二进制文件评估为文本文件，这是一个重要的警告，因为 git 会破坏您的二进制文件。

基本上，以前是 LF 的本地文件现在在本地具有 CRLF

【讨论】：

【解决方案6】：

--7月9日更新---

删除了@mgiuca 评论的“它是正确和准确的”

======

否。它不是在谈论您当前使用CRLF 的文件。而是用LF 讨论文件。

应该是：

警告：（如果您使用当前的 core.autocrlf 配置检查它/或克隆到另一个文件夹，）LF 将被 CRLF 替换

该文件将在您的（当前）工作目录中具有其原始行结尾。

这张图片应该解释它的含义。

【讨论】：

对我有用的是：1) core.autocrlf=false 2) 在 Intellij 中设置行分隔符 (\n)。我在 Mac 和 Windows 上都使用 Intellij Idea。
当文件在 Windows 中创建但具有 unix/mac 行结尾 (lf) 并且您的 git config 属性 autocrlf 为 true 时，可能会发生这种情况。本质上 git 不会更改您创建的文件，但它会用 Windows 行结尾检查/克隆它（因为您的 autocrlf 设置）
如果您必须使用“如果您使用当前的 core.autocrlf 配置检查它/或克隆到另一个文件夹”来限定它，那么该警告如何正确和准确。这不是原始消息所说的。它说它将（不会）被 CRLF 取代，这意味着它将以 CRLF 模式存储在 repo 本身中，而不是在某些假设的未来结帐中。

【解决方案7】：

git config --global core.autocrlf false 适用于全局设置。

但如果您使用的是 Visual Studio，可能还需要为某些类型的项目（例如 c# 类库应用程序）修改.gitattributes：

删除行* text=auto

【讨论】：

【解决方案8】：

如果您使用的是 Visual Studio 2017、2019，您可以：

打开主.gitignore（在解决方案的其他项目中更新或删除其他.gitignore文件）
粘贴以下代码：

[core]
 autocrlf = false
[filter "lfs"]
 required = true
 clean = git-lfs clean -- %f
 smudge = git-lfs smudge -- %f
 process = git-lfs filter-process

【讨论】：

那个“代码”看起来应该在像.gitconfig或.git/config这样的配置文件中，而不是.gitignore，它指定了要被git忽略的文件。
我将此添加到 .git/config 但仍然出现“警告：CRLF 将被 LF 替换”

【解决方案9】：

我遇到了类似的问题，在 Windows 上使用 vscode(v1.57) 尝试了其他答案中定义的解决方案，但没有奏效。

所以对我来说，以下步骤有效：

在根文件夹中有一个名为 .editorconfig 的文件
打开此文件并将end_of_line = lf 更改为end_of_line = crlf
运行git rm --cached，警告消失了！！

【讨论】：

【解决方案10】：

确保您在.gitignore 文件中添加了不必要的文件或文件夹。

例如 node_modules

如果仍然面对则运行此命令

``git config --global core.autocrlf false```

【讨论】：

【解决方案11】：

发生这种情况是因为 Windows 上的 GitHub Desktop 的配置假定为 CRLF，但文本编辑器可能正在使用 LF。您可以将本地存储库设置更改为使用 lf。

导航到 git repo 的根目录并以完全相同的顺序执行此操作

git config core.eol lf
git config core.autocrlf input

Source: GitHub issue

【讨论】：

【解决方案12】：

关闭 Visual Studio

如果您收到错误，一个简单的修复方法是关闭 Visual Studio，然后您可以提交到 main，就这么简单。我有同样的问题，这就是我解决它的方法。这是因为您要打开的文件在另一个程序中打开。

【讨论】：

我不知道这可能与此处询问的行尾问题有关。你能澄清一下联系吗？