Windows git &quot警告:LF将被CRLF&quot取代，这是警告尾巴向后?

警告:LF将被CRLF取代。

根据你所使用的编辑器，带有LF的文本文件不一定要用CRLF保存:最近的编辑器可以保存 eol样式。但是git的配置设置坚持要更改这些…

简单地确保(作为我在这里推荐):

git config --global core.autocrlf false

这样，就避免了任何自动转换，并且仍然可以通过.gitattributes文件和core.eol指令指定它们。

windows git "LF将被CRLF"取代;

注意:警告信息已更改到Git 2.37 (Q3 2022)

这个警告尾巴是向后的吗?

不:你在Windows上，并且git config帮助页面确实提到

如果你想在你的工作目录中有CRLF行结束符，即使存储库没有规范化的行结束符，也可以使用此设置。

如“__abc1”中所述，它应该只在签出时发生(未提交)，与core.autocrlf=true。

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

正如在XiaoPeng的回答中提到的，该警告与:

警告:(如果你将它检出/或克隆到另一个具有当前core.autocrlf配置的文件夹中，)LF将被CRLF
取代 该文件将在您的(当前)工作目录中有其原始的行结束符

正如在git-for-windows/git issue 1242中提到的:

我仍然觉得这条消息令人困惑，该消息可以扩展到包括一个更好的解释的问题，例如:“在删除文件并再次检查后，LF将被file.json中的CRLF所取代”。

正如quaylar正确地评论一样，如果在提交时存在转换，则仅转换为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年第二季度)中，代码清理增加了一些解释。

参见提交8462年ff4 (13 Jan 2018) by Torsten Bögershausen (tboegi)。
^{(由Junio C Hamano—gitster—在提交9 bc89b1中合并，13 Feb 2018)}

Convert_to_git (): safe_crlf/checksafe变成int conv_flags

当调用convert_to_git()时，checksafe形参定义了what 应该发生，如果EOL转换(CRLF --> LF --> CRLF)没有 往返干净。
此外，它还定义了行结束符是否应该重新正规化(CRLF --> LF)或保持原样

checksafe是一个包含以下值的safe_crlf enum:

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

参见提交6 cb0912 (04 Jun 2018) by Anthony Sottile (asottile)。
^{(由Junio C Hamano—gitster—在提交8063年ff9中合并，28 Jun 2018)}

在我设置core.autocrlf=true之后，我得到了“LF将被CRLF取代”(注意不是“CRLF将被LF取代”)，当我在git adding(或者可能是在git commit上?)在库(确实使用LF)的窗口中编辑的文件被签出之前时，我设置了core.autocrlf=true。

我用core.autocrlf=true做了一个新的签出，现在我没有得到这些消息。

做一些简单的事情:

1. 打开git-hub (Shell)并导航到目录文件属于(cd /a/b/c/…)
2. 执行dos2unix(有时是dos2unix.exe)
3. 现在尝试提交。 如果你再次得到相同的错误。 执行以上所有步骤，除了不执行dos2unix，而是执行unix2dox (unix2dos.exe sometimes)

是的警告是反的。

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

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

当前形式的警告是以下两件事之一:

1. 一个不幸的错误加上一个过于谨慎的警告信息， 李或< / >
2. 一个非常聪明的情节，让你真的思考这个…

；）

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

原始错误:

警告:LF将被CRLF
取代 该文件在您的工作目录中有其原始的行结束符。< / p >

错误应该是什么:

警告:LF将被CRLF 在工作目录中
取代 该文件将有其原来的LF行结束在git存储库中

解释在这里:

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

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

——7月9日更新——

删除“正确无误”;正如@mgiuca所评论的

= = = = = =

没有。它不是在谈论你当前的文件CRLF。相反，它谈论的是LF文件。

它应该是:

(如果你签出/或克隆到另一个文件夹与你当前的核心。autocrlf配置，)LF将被CRLF取代

该文件将在你的(当前的)工作目录中有它原来的行结束符。

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

但如果你正在使用Visual Studio，可能还需要为某些类型的项目(例如c#类库应用程序)修改.gitattributes:

• 删除行* text=auto

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

所以对我来说，以下步骤是有效的:

1. 在根文件夹中有一个名为.editorconfig的文件
2. 打开这个文件，用end_of_line = crlf改变end_of_line = lf
3. 运行git rm --cached，警告消失!!

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

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

git配置——全局核心。autocrlf假的' '

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

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

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

来源:GitHub issue

关闭Visual Studio

这个警告尾巴是向后的吗?

参见提交c970d30 (07 Apr 2022) by Alex Henrie (alexhenrie)。
^{(由Junio C Hamano—gitster—在提交0 a88638中合并，20 May 2022)}

convert:澄清行结束转换警告

^{署名:Alex Henrie}

关于转换行尾的警告非常令人困惑。

LF will be replaced by CRLF in ...
The file will have its original line endings in your working directory.

它的两个句子都使用了单词“will”;没有指定一个时间范围，这让它听起来像是两个句子指的是同一个时间范围。
最重要的是，它使用了“原行结尾”一词;没有说是否“原创”;

重新措辞警告，以明确何时将更改行结束符以及将更改为什么。

在本机行结束符不是CRLF的平台上(例如Linux)，以下序列中的“git add"^(man)步骤会触发所讨论的新消息(不再有警告):

$ git config core.autocrlf true
$ echo 'Hello world!' >hello.txt
$ git add hello.txt


In the working copy of 'hello.txt', CRLF will be replaced by LF
the next time Git touches it.

并且在本机行结束符不是LF的平台上(例如窗户)，下面序列中的" git add" ^(man)步骤会触发所讨论的新消息(不再有警告):

$ git config core.autocrlf true
$ echo 'Hello world!' >hello.txt
$ git add hello.txt


In the working copy of 'hello.txt', LF will be replaced by CRLF
the next time Git touches it.