当前位置：theitroad>Windows git“警告：LF 将被 CRLF 替换”，那个警告尾部是向后的吗？

Windows git“警告：LF 将被 CRLF 替换”，那个警告尾部是向后的吗？

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/17628305/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-09-10 16:33:09 　来源:igfitidea点击:

Windows git "warning: LF will be replaced by CRLF", is that warning tail backward?

git

提问by Honghe.Wu

env:

环境：

  • Windows 7
  • msysgit
  • Windows 7的
  • 管理系统

Wheng I git commit, it says:

当我git commit，它说：

warning: LF will be replaced by CRLF.

Is this warning tail backward?
I edit file in Windows, the end of line is CRLF, just like this pic:
enter image description here
And git changes it to LFfor committing to repo.
So I think the correct warning is:

这个警告尾巴是向后的吗？
我在 Windows 中编辑文件，行尾是CRLF，就像这张图片：
在此处输入图片说明
并且 git 将其更改LF为提交到 repo。
所以我认为正确的警告是： 

warning: CRLF will be replaced by LF.

回答by VonC

warning: LF will be replaced by CRLF.

警告：LF 将被 CRLF 替换。

Depending on the editor you are using, a text file with LF wouldn't necessary be saved with CRLF: recent editors can preserveeol style. But that git config setting insists on changing those...

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

Simply make sure that (as I recommend here):

只需确保（正如我在此处推荐的那样）：

git config --global core.autocrlf false

That way, you avoid any automatic transformation, and can still specify them through a .gitattributesfileand core.eoldirectives.

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

windows git "LF will be replaced by CRLF"
Is this warning tail backward?

windows git“LF将被CRLF取代”
这个警告尾部是否向后？

No: you are on Windows, and the git confighelp pagedoes mention

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

Use this setting if you want to have CRLFline endings in your working directory even though the repository does not have normalized line endings.

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

As described in "git replacing LF with CRLF", it should only occur on checkout(not commit), with core.autocrlf=true.

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

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

As mentioned in XiaoPeng's answer, that warning is the same as:

正如小鹏的回答中提到 的，该警告与以下内容相同：

warning: (If you check it out/or clone to another folder with your current core.autocrlfconfiguration,) LF will be replaced by CRLF
The file will have its original line endings in your (current) working directory.

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

As mentioned in git-for-windows/gitissue 1242:

如git-for-windows/git第 1242 期所述：

I still feel this message is confusing, the message could be extended to include a better explanation of the issue, for example: "LF will be replaced by CRLF in file.jsonafter removing the file and checking it out again".

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

Note: Git 2.19 (Sept 2018), when using core.autocrlf, the bogus "LF will be replaced by CRLF" warning is now suppressed.

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

As quaylarrightly comments, if there is a conversion on commit, it is to LFonly.

正如quaylar正确评论的那样，如果在提交时进行了转换，则只有 to LF。

That specific warning "LF will be replaced by CRLF" comes from convert.c#check_safe_crlf():

该特定警告“ 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);

It is called by convert.c#crlf_to_git(), itself called by convert.c#convert_to_git(), itself called by convert.c#renormalize_buffer().

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

And that last renormalize_buffer()is only called by merge-recursive.c#blob_unchanged().

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

So I suspect this conversion happens on a git commitonly if said commit is part of a merge process.

所以我怀疑git commit只有当所述提交是合并过程的一部分时才会发生这种转换。

Note: with Git 2.17 (Q2 2018), a code cleanup adds some explanation.

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

See commit 8462ff4(13 Jan 2018) by Torsten B?gershausen (tboegi).
(Merged by Junio C Hamano -- gitster--in commit 9bc89b1, 13 Feb 2018)

请参阅Torsten B?gershausen ( )提交的 8462ff4(2018 年 1 月 13 日)。（由Junio C Hamano合并-- --在提交 9bc89b1，2018 年 2 月 13 日）tboegi
gitster

convert_to_git(): safe_crlf/checksafe becomes int conv_flags

When calling convert_to_git(), the checksafeparameter defined what should happen if the EOL conversion (CRLF --> LF --> CRLF) does not roundtrip cleanly.
In addition, it also defined if line endings should be renormalized (CRLF --> LF) or kept as they are.

checksafe was an safe_crlfenum with these values:

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

Note that a regression introduced in 8462ff4("convert_to_git(): safe_crlf/checksafebecomes int conv_flags", 2018-01-13, Git 2.17.0) back in Git 2.17 cycle caused autocrlfrewrites to produce a warning message despite setting safecrlf=false.

请注意，在 Git 2.17 周期中8462ff4（“ convert_to_git(): safe_crlf/checksafe变为int conv_flags”，2018-01-13，Git 2.17.0）中引入的回归导致autocrlf重写， 尽管设置了safecrlf=false.

See commit 6cb0912(04 Jun 2018) by Anthony Sottile (asottile).
(Merged by Junio C Hamano -- gitster--in commit 8063ff9, 28 Jun 2018)

请参阅Anthony Sottile( )提交的 6cb0912(2018 年 6 月 4 日)。（由Junio C Hamano合并-- --在8063ff9 提交中，2018 年 6 月 28 日）asottile
gitster

回答by Stijn de Witt

YESthe warning is backwards.

是的警告是倒退的。

And in fact it shouldn't even be a warning in the first place. Because all this warning is saying (but backwards unfortunately) is that the CRLF characters in your file with Windows line endings will be replaced with LF's on commit. Which means it's normalized to the same line endings used by *nix and MacOS.

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

Nothing strange is going on, this is exactly the behavior you would normally want.

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

This warning in it's current form is one of two things:

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

  1. An unfortunate bug combined with an over-cautious warning message, or
  2. A very clever plot to make you reallythink this through...
  1. 一个不幸的错误与过度谨慎的警告信息相结合，或
  2. 一个非常聪明的情节，让你真正思考这个......

;)

;)

回答by Xiao Peng - ZenUML.com

--Update on 9th July---

——7月9日更新——

Removed "It is correct and accurate" as commented by @mgiuca

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

======

======

NO. It is NOT talking about your files currently with CRLF. It is instead talking about files with LF.

否。它不是在谈论您当前使用CRLF. 相反，它是在谈论带有LF.

It should read:

它应该是：

warning: (If you check it out/or clone to another folder with your current core.autocrlf configuration,)LF will be replaced by CRLF

The file will have its original line endings in your (current) working directory.

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

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

This picture should explain what it means. enter image description here

这张图应该解释了它的意思。 在此处输入图片说明

回答by mikew

All of this assumes core.autocrlf=true

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

Original error:

原始错误：

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

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

What the error SHOULD read:

错误应该是什么：

warning: LF will be replaced by CRLF in your working directory
The file will have its original LF line endings in the git repository

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

Explanation here:

这里的解释：

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，它将像往常一样与 LF 一起存储，但在检查时稍后它会有 CRLF 结尾。对于普通的文本文件，这通常很好。在这种情况下，警告是“供您参考”，但如果 git 错误地将二进制文件评估为文本文件，这是一个重要的警告，因为 git 会破坏您的二进制文件。

Basically, a local file that was previously LF will now have CRLF locally

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

回答by Eric Wang

git config --global core.autocrlf falseworks well for global settings.

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

But if you are using Visual Studio, might also need to modify .gitattributesfor some type of projects (e.g c# class library application):

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

  • remove line * text=auto
  • 删除线 * text=auto

回答by Marsette Vona

After I set core.autocrlf=trueI was getting "LF will be replaced by CRLF" (note not "CRLF will be replaced by LF") when I was git adding (or perhaps it was it on git commit?) edited files in windows on a repository (that does use LF) that was checked out beforeI set core.autocrlf=true.

在我设置后，core.autocrlf=true当我在存储库上的 Windows 中编辑文件git add（或者它可能是它git commit？）时，我收到“LF 将被 CRLF 替换”（注意不是“CRLF 将被 LF 替换”）LF)在我设置core.autocrlf=true.

I made a new checkout with core.autocrlf=trueand now I'm not getting those messages.

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

回答by Antriksh Jain

Do just simple thing: 1. Open git-hub (Shell) and navigate to the directory file belongs to (cd /a/b/c/...) 2. Execute dos2unix (sometime dos2unix.exe) 3. Try commit now. If you get same error again. Perform all above steps except instead of dos2unix, do unix2dox (unix2dos.exe sometime)

做一些简单的事情： 1. 打开 git-hub (Shell) 并导航到属于 (cd /a/b/c/...) 的目录文件 2. 执行 dos2unix（有时是 dos2unix.exe） 3. 立即尝试提交. 如果再次出现同样的错误。执行上述所有步骤，除了 dos2unix，执行 unix2dox (unix2dos.exe sometime)

回答by Javier Ca?on

If you are using Visual Studio 2017, 2019, you can:

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

  1. open the main .gitignore (update or remove anothers .gitignore files in others projects in the solution)
  2. paste the below code:
  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

相关推荐

为什么 Git 允许我创建两个同名的分支？

为什么 Git 允许我创建两个同名的分支？

有没有办法让 git-reflog 在每个条目旁边显示一个日期？

有没有办法让 git-reflog 在每个条目旁边显示一个日期？

如何删除在桌面上创建的 git 存储库

如何删除在桌面上创建的 git 存储库

将 Git 存储库内容移动到另一个存储库以保留历史记录

将 Git 存储库内容移动到另一个存储库以保留历史记录

相关推荐
最近更新
标签