Windows git“警告：LF将被CRLF取代”，该警告尾是否向后？

环境：

• Windows 7的
• msysgit

当我git commit说：

warning: LF will be replaced by CRLF. 

这个警告尾巴向后吗？
我在Windows中编辑文件，此行的结尾是CRLF，如图所示：

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

warning: CRLF will be replaced by LF. 

警告：LF将被CRLF取代。

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

只需确保（如我在这里推荐）：

git config --global core.autocrlf false

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

Windows git“ LF将被CRLF替换”
这条警告尾是否向后？

否：您使用的是Windows，并且git config帮助页面上确实提到了

即使您CRLF的存储库中没有标准化的行尾，也要在工作目录中使用行尾，请使用此设置。

如“ 用CRLF替换LF的git ”中所述，它仅应在结帐时（而不是提交时）通过进行core.autocrlf=true。

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

如 小鹏的回答所述，该警告与以下内容相同：

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

如git-for-windows/git问题1242中所述：

我仍然感到此消息令人困惑，该消息可以扩展为包含对该问题的更好的解释，例如：“ file.json在删除文件并再次签出后，LF将由CRLF替换。”

注意：Git 2.19（2018年9月）在使用时core.autocrlf，现在已取消了伪造的“ LF将被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年第二季度）中，代码清理添加了一些解释。

见提交8462ff4（2018年1月13日）由托斯滕Bögershausen（ ）tboegi。
^{（通过合并JUNIOÇ滨野- gitster-在提交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

请注意，在Git 2.17周期中，在8462ff4中引入的回归（“ convert_to_git()： safe_crlf/checksafe变为int conv_flags”，2018-01-13，Git 2.17.0）导致尽管设置，但autocrlf重写仍会产生警告消息 。safecrlf=false

参见Anthony Sottile（）提交6cb0912（2018年6月4日）。^{（通过合并JUNIOÇ滨野- -在提交8063ff9 6月28日2018）}asottile
gitster

是的，警告是向后的。

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

没什么奇怪的，这正是您通常想要的行为。

当前形式的警告是两件事之一：

1. 不幸的错误加上过分谨慎的警告消息，或者
2. 一个非常聪明的情节，可以让您真正地考虑一下...

;）

-7月9日更新-

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

======

NO。并不是说您目前使用的文件CRLF。而是用谈论文件LF。

它应显示为：

警告：（如果您将其签出/或使用当前core.autocrlf配置克隆到另一个文件夹，）LF将替换为CRLF

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

该图片应说明其含义。

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

原始错误：

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

错误应显示为：

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

在这里说明：

这种便捷转换的副作用是警告，它的意思是，如果您最初编写的文本文件以LF结尾而不是CRLF，它将照常与LF一起存储，但是在选中时以后将有CRLF结尾。对于普通的文本文件，通常就可以了。在这种情况下，警告是“仅供参考”，但是如果git错误地将二进制文件评估为文本文件，则这是一个重要的警告，因为git会破坏您的二进制文件。

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

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

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

• 删除线 * text=auto

之后我把core.autocrlf=true我得到的“LF将CRLF改为”（注意不是“CRLF将被替换为LF”）我是在git add荷兰国际集团（或者也许是它的git commit编辑？）在Windows文件上的存储库（即不使用LF）在我设置之前已签出core.autocrlf=true。

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

如果您使用的是Visual Studio 2017、2019，则可以执行以下操作：

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

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

做简单的事情：

1. 打开git-hub（Shell）并导航到目录文件（cd / a / b / c / ...）
2. 执行dos2unix（有时是dos2unix.exe）
3. 立即尝试提交。如果再次遇到相同的错误。执行上述所有步骤，但不使用dos2unix，而是执行unix2dox（有时是unx2dos.exe）