警告:LF将被CRLF取代。

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

只要确保(正如我在这里建议的):

git config --global core.autocrlf false

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

---

windows git“LF将被CRLF取代”

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

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

不:你在Windows上，git配置帮助页面确实提到了

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

正如“git用CRLF替换LF”中所描述的，它应该只发生在签出(而不是提交)时，core. selflf =true。

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

正如小鹏的回答中提到的，这个警告是:

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

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

我仍然觉得这条消息令人困惑，这条消息可以扩展到包括一个更好的解释，例如:“LF将被文件中的CRLF取代。Json后删除文件并再次签出”。

注意:Git 2.19(2018年9月)，当使用核心。专制者，虚假的“LF” “CRLF”的警告现在被压制。

---

正如quaylar正确地评论的那样，如果在commit上有一个转换，它只是到LF。

特定的警告“LF将被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()调用。

所以我怀疑只有当提交是merge过程的一部分时，这种转换才会发生在git提交上。

---

注意:在Git 2.17(2018年第二季度)中，代码清理增加了一些解释。

参见Torsten提交8462ff4(2018年1月13日)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参数定义了what 如果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周期导致selflf重写产生警告消息 尽管设置了safecrlf=false。

参见Anthony Sottile (asottile)提交的commit 6cb0912(2018年6月04日)。 (由Junio C Hamano—gitster—在commit 8063ff9中合并，2018年6月28日)

在我设定核心之后。我得到了“LF将被CRLF取代”(注意不是“CRLF将被LF取代”)当我在git添加(或者可能是它在git提交?)编辑文件在窗口上的存储库(使用LF)，在我设置core. selflf =true之前签出。

我用core做了一个新的结账。selflf =true，现在我没有得到这些消息。

做一些简单的事情:

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

是的，警告是反的。

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

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

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

一个不幸的漏洞加上一个过于谨慎的警告信息， 或 一个非常聪明的情节，让你真正思考这个问题……

;)

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

原始错误:

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

错误应该是什么:

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

解释:

The side-effect of this convenient conversion, and this is what the warning you're seeing is about, is that if a text file you authored originally had LF endings instead of CRLF, it will be stored with LF as usual, but when checked out later it will have CRLF endings. For normal text files this is usually just fine. The warning is a "for your information" in this case, but in case git incorrectly assesses a binary file to be a text file, it is an important warning because git would then be corrupting your binary file.

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

——7月9日更新——

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

= = = = = =

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

它应该是:

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

这张图可以解释它的意思。

Git配置——全局核心。selff false适用于全局设置。

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

删除line * text=auto

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

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

在根文件夹中有一个名为.editorconfig的文件 打开该文件，将end_of_line = lf修改为end_of_line = CRLF 运行git rm——缓存，警告消失!!

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

如。 node_modules

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

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

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

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

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

来源:GitHub问题

关闭Visual Studio

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

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

这一警告首先令人困惑。 Git 2.37 (Q3 2022)对其进行了改写和澄清。

参见Alex Henrie (alexhenrie)提交c970d30 (07 Apr 2022)。 (由Junio C Hamano—gitster—在提交0a88638中合并，2022年5月20日)

转换:澄清行结束转换警告 署名:Alex Henrie

The warning about converting line endings is extremely confusing. LF will be replaced by CRLF in ... The file will have its original line endings in your working directory. Its two sentences each use the word "will" without specifying a timeframe, which makes it sound like both sentences are referring to the same timeframe. On top of that, it uses the term "original line endings" without saying whether "original" means LF or CRLF. Rephrase the warning to be clear about when the line endings will be changed and what they will be changed to.

在本机行结束符不是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的平台上(例如Windows)，下面序列中的“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.