警告: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取代。

根据您使用的编辑器的不同，带有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使用的相同的行结束符。

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

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

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

;)

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

这一警告首先令人困惑。 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.