Git用CRLF替换LF

在Windows机器上，我使用git add添加了一些文件。我收到警告说：

LF将被CRLF取代

这种转换的后果是什么？

907594 次浏览
小开

我对Windows上的Git了解不多，但…

在我看来，Git正在转换返回格式以匹配运行平台（Windows）的返回格式。CRLF是Windows上的默认返回格式，而LF是大多数其他操作系统的默认返回格式。

当代码移动到另一个系统时，返回格式很可能会被正确调整。我还认为Git足够聪明，可以保持二进制文件完整，而不是尝试将jpeg文件中的LF转换为CRLF。

总之，你可能不需要为此转换而烦恼太多。但是，如果你将项目存档为tarball，其他编码人员可能会喜欢使用LF行终止符而不是CRLF。根据你的关心程度（以及取决于你不使用记事本），如果可以，你可能希望将Git设置为使用LF返回：）

附录：CR是ASCII代码13，LF是ASCII代码10。因此，CRLF是两个字节，而LF是一个字节。

小开

Git有三种处理行尾的模式：

# This command will print "true" or "false" or "input"git config core.autocrlf

您可以通过在上面的命令行中添加true或false的附加参数来设置要使用的模式。

如果core.autocrlf设置为true，这意味着任何时候你向Git存储库添加一个Git认为是文本文件的文件，它都会在将其存储在提交中之前将所有CRLF行结尾转换为LF。每当你git checkout某物时，所有文本文件都会自动将其LF行结尾转换为CRLF结尾。这允许跨平台开发使用不同行结尾样式的项目，而不会提交非常嘈杂，因为每个编辑器都会更改行结尾样式，因为行结尾样式始终是一致的LF。

这种方便的转换的副作用，这就是你看到的警告，如果你创作的文本文件最初有LF结尾而不是CRLF，它将像往常一样与LF一起存储，但稍后签出时它将有CRLF结尾。对于普通文本文件，这通常没问题。在这种情况下，警告是“供您参考”，但如果Git错误地将二进制文件评估为文本文件，这是一个重要的警告，因为Git会破坏您的二进制文件。

如果core.autocrlf设置为false，则不会执行行尾转换，因此文本文件会按原样签入。这通常可以正常工作，只要您的所有开发人员都在Linux或全部在Windows上。但根据我的经验，我仍然倾向于使用混合行尾的文本文件，最终会导致问题。

作为Windows开发人员，我个人的偏好是保持设置打开。

有关包括“输入”值的更新信息，请参阅git-config。

小开

我也有这个问题。

SVN不做任何行结束转换，所以文件是在CRLF行结束完好无损的情况下提交的。如果你然后使用git-svn将项目放入git，那么CRLF结束会持续到git存储库中，这不是git期望自己处于的状态——默认情况是只有unix/linux（LF）行结束签入。

当您在Windows上签出文件时，autocrlf转换会使文件保持不变（因为它们已经具有当前平台的正确结尾），但是决定是否与签入文件存在差异的过程执行反向转换之前比较，导致比较它认为签出文件中的LF与存储库中的意外CRLF。

据我所知，你的选择是：

  1. 在不使用git-svn的情况下将代码重新导入到新的git存储库中，这将意味着行结尾在初始git提交中转换
  2. 将autocrlf设置为false，并忽略行结尾不是git首选样式的事实
  3. 关闭autocrlf检查您的文件，修复所有行结尾，检查所有内容，然后再次打开它。
  4. 重写存储库的历史记录，以便原始提交不再包含git不期望的CRLF。（关于历史重写的通常警告适用）

脚注：如果您选择选项#2，那么我的经验是，一些辅助工具（rebase，补丁等）无法处理CRLF文件，您迟早会使用混合了CRLF和LF（不一致的行结尾）的文件。我知道没有办法充分利用两者。

小开

在GNU/Linuxshell提示符中，dos 2unix和unix2dos命令允许您轻松转换/格式化来自MS Windows的文件。

小开

unix2dos和dos 2unix都可在带有gitbash的Windows上使用。您可以使用以下命令执行UNIX（LF）→DOS（CRLF）转换。因此，您不会收到警告。

unix2dos filename

或

dos2unix -D filename

但是，不要在任何现有的CRLF文件上运行此命令，因为这样你每隔两行就会得到空的换行符。

dos2unix -D filename不适用于所有操作系统。请检查此链接的兼容性。

如果出于某种原因，您需要强制执行命令，请使用--force。如果它说无效，请使用-f。

小开

在Vim中，打开文件（例如：:e YOURFILE输入），然后

:set noendofline binary:wq
小开

从~/. git属性文件中删除以下内容，

* text=auto

将首先阻止Git检查行尾。

小开
  1. 在记事本++中打开文件。
  2. 转到菜单编辑→停产转正。
  3. 点击windows格式。
  4. 保存文件。
小开

这些消息是由于Windows上不正确的默认值core.autocrlf造成的。

autocrlf的概念是透明地处理行结束转换。

坏消息：需要手动配置值。

好消息：每个Git安装只应该完成一个次（每个项目设置也是可能的）。

#0如何工作：

core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:
repository               repository               repository^      V                 ^      V                 ^      V/        \               /        \               /        \crlf->lf    lf->crlf     crlf->lf       \             /          \/            \           /            \           /            \

这里crlf=win样式的行尾标记，lf=unix样式（自Mac OS X以来也在Mac上使用）。

（pre-osxcr不受上述三个选项中任何一个的影响。

此警告何时显示（在Windows下）？

-autocrlf=true如果您的一个文件中有unix风格的lf（=很少），
    -autocrlf=input，如果您在其中一个文件中有win-stylecrlf（=几乎总是），
    -autocrlf=false-永远不要！

这个警告是什么意思？

警告“LF将被CRLF取代”表示您（具有autocrlf=true）将在提交-结帐周期后丢失您的unix样式LF（它将被windows样式CRLF取代）。Git不希望您在Windows下使用unix样式LF。

警告“CRLF将被LF取代”表示您（具有autocrlf=input）将在提交-签出周期后丢失Windows样式的CRLF（它将被unix样式的LF替换）。不要在Windows下使用input。

autocrlf是如何工作的

1) true:             x -> LF -> CRLF2) input:            x -> LF -> LF3) false:            x -> x -> x

其中x是CRLF（windows样式）或LF（unix样式），箭头代表

file to commit -> repository -> checked out file

如何修复

core.autocrlf的默认值是在Git安装过程中选择的，并存储在系统范围的gitconfig中（Windows上为%ProgramFiles(x86)%\git\etc\gitconfig，Linux上为/etc/gitconfig）。还有（按以下顺序级联）：

-位于~/.gitconfig的“全局”（每个用户）gitconfig，还有一个
   -“全局”（每个用户）gitconfig在$XDG_CONFIG_HOME/git/config或$HOME/.config/git/config和
   -工作目录中.git/config处的“本地”（per-repo）gitconfig。

所以，在工作目录中写入git config core.autocrlf来检查当前使用的值和

-git config --system core.autocrlf false#每系统解决方案
   -git config --global core.autocrlf false#每用户解决方案
   -git config --local core.autocrlf false#每个项目的解决方案

警告

-git config设置可以被gitattributes设置覆盖。
    -crlf -> lf转换仅在添加新文件时发生，crlf存储库中已经存在的文件不受影响。

道德（Windows）：

-如果您也计划在Unix下使用此项目（并且不愿意将您的编辑器/IDE配置为使用unix行结尾），请使用core.autocrlf=true，
    -如果您计划仅在Windows下使用此项目（或者您已将编辑器/IDE配置为使用unix行结尾），请使用core.autocrlf=false，
    -从未使用core.autocrlf=input，除非您有充分的理由（eg，如果您在Windows下使用unix实用程序或遇到makefile问题），

ps安装Git for Windows时如何选择？

如果您不打算在Unix下使用您的任何项目，不要同意默认的第一个选项。选择第三个（按原样签出，按原样提交）。您不会看到此消息。永远。

PPS：我个人的偏好是将编辑器/IDE配置为使用unix风格的结尾，并将core.autocrlf设置为false。

更新（2022）

自2018年以来，git可以重新规范化 repo根据需要修复现有的行尾。

小开 
git config core.autocrlf false
小开

我认为Basiloungas的回答很接近，但已经过时了（至少在Mac上）。

打开~/. gitconfig文件并将safecrlf设置为false：

[core]autocrlf = inputsafecrlf = false

这将使它忽略行char的末尾（它对我有效，无论如何）。

小开

如何使Git忽略不同的行结束

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/（不工作）

您可以完全禁用CRLF行为，或者通过更改. git属性文件中的条目来禁用每个文件类型。在我的例子中，我这样写：

  • -crlf这告诉Git忽略所有文件的行结尾。并且不会更改您工作目录中的文件。即使您将core.autocrlf设置为true、false或输入。
echo "* -crlf" > .gitattributes

在单独的提交上执行此操作，否则当您进行单个更改时，Git可能仍会看到整个文件被修改（取决于您是否更改了autocrlf选项）。

这个真的很有效。Git会尊重混合行尾项目中的行尾，不会警告你。

小开

OP的问题是与Windows相关的，我不能使用其他人而不去目录，甚至在记事本++中运行文件，因为管理员不工作…

所以不得不走这条路：

cd "C:\Program Files (x86)\Git\etc"git config --global core.autocrlf false
小开

如果您已经签出代码，则文件已经被索引。更改Git设置后，例如运行：

git config --global core.autocrlf input

您应该使用

git rm --cached -r .

然后重写Git索引

git reset --hard

注意：这将删除您的本地更改。在执行此操作之前，请考虑隐藏它们。

来源：配置Git以处理行结束

小开

在谈论这个话题时，通常会提到关于行结尾的GitHub文章。

我个人使用经常推荐的core.autocrlf配置设置的经验非常复杂。

我正在使用带有Cygwin的Windows，在不同的时间处理Windows和Unix项目。甚至我的Windows项目有时也使用Bash shell脚本，这需要Unix（LF）行结尾。

使用GitHub推荐的Windowscore.autocrlf设置，如果我签出一个Unix项目（它在Cygwin上运行良好-或者我正在为我在Linux服务器上使用的项目做出贡献），文本文件将使用Windows（CRLF）行结尾签出，从而产生问题。

基本上，对于像我这样的混合环境，将全局core.autocrlf设置为任何选项在某些情况下都不会很好地工作。此选项可能设置在本地（存储库）Git配置上，但即使如此，对于包含Windows和Unix相关内容的项目来说也不够好（例如，我有一个带有一些Bash实用脚本的Windows项目）。

我发现的最佳选择是创建每个存储库. git属性文件。github文章提到了它。

这篇文章的例子：

# Set the default behavior, in case people don't have core.autocrlf set.* text=auto
# Explicitly declare text files you want to always be normalized and converted# to native line endings on checkout.*.c text*.h text
# Declare files that will always have CRLF line endings on checkout.*.sln text eol=crlf
# Denote all files that are truly binary and should not be modified.*.png binary*.jpg binary

在我的一个项目的存储库中：

* text=auto
*.txt         text eol=lf*.xml         text eol=lf*.json        text eol=lf*.properties  text eol=lf*.conf        text eol=lf
*.awk  text eol=lf*.sed  text eol=lf*.sh   text eol=lf
*.png  binary*.jpg  binary
*.p12  binary

要设置的东西有点多，但是每个项目都要做一次，并且任何操作系统上的任何贡献者在使用此项目时都应该不会遇到行结尾的问题。

小开

应改为：

警告：（如果您签出/或克隆到另一个文件夹，您的当前core.autocrlf为#0，）LF将被CRLF替换

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

这张照片应该解释它的意思。

在此输入图片描述

小开

许多文本编辑器允许您更改为LF。请参阅下面的Atom说明。它简单而明确。

点击右下角的CRLF：

在此输入图片描述

在顶部的下拉列表中选择LF：

在此输入图片描述

小开

在两个不同的操作系统（Linux和Windows）中使用您的“代码”时，CRLF可能会导致一些问题。

我的Python脚本是在Linuxdocker容器中编写的，然后使用Windowsgitbash推送。它警告我LF将被CRLF取代。我没有多想，但后来当我启动脚本时，它说：

/usr/bin/env：'python\r'：没有这样的文件或目录

现在这是您的分支的\r。Windows使用“CR”-回车-在“\n”之上作为新行字符-\n\r。这是您可能必须考虑的事情。

小开

确保您已安装最新版本的Git

在使用Git（版本2.7.1）时，我按照前面的答案git config core.autocrlf false做了，但它不起作用。

然后它现在可以在升级git（从2.7.1到2.20.1）时工作。

小开

Windows中的大多数工具也接受文本文件中的简单LF。例如，您可以在名为“. editorconfig”的文件中控制Visual Studio的行为，其中包含以下示例内容（部分）：

 indent_style = spaceindent_size = 2end_of_line = lf    <<====charset = utf-8

只有原始的Windows记事本不适用于LF，但有一些更合适的简单编辑器工具可用！

因此，您也应该在Windows中的文本文件中使用LF。这是我的信息，强烈推荐！没有任何理由在Windows中使用CRLF！

（同样的讨论是在C/++中的包含路径中使用\。这是牛的粪便问题。使用带斜杠的#support！，这是C/++标准，所有Microsoft编译器都支持它）。

因此，Git的正确设置是：

git config core.autocrlf false

我的信息：忘记像dos 2unix和unix2dos这样的旧思维程序。在你的团队中澄清LF适合在Windows下使用。

小开

其他答案对于一般概念来说非常棒。我遇到了一个问题，在更新后，警告仍然发生在先前设置中有提交的现有存储库上。

添加重新规范化帮助，例如，

git add --renormalize .

从留档：

"将"清洁"进程应用于所有跟踪的文件以强制执行将它们再次添加到索引中。更改后这很有用core.autocrlf配置或文本属性，以便更正添加了错误的CRLF/LF行结尾的文件。此选项意味着-u。”

小开

我有同样的问题，做git add . && git reset恢复所有行结束正确。

小开

我犯了同样的错误。它发生在Windows 10上安装NVMNVM之后。

在所有级别设置高压灭菌器不起作用。

在CMD中，我使用：“git ls-files--eol”

i/lf    w/crlf  attr/             src/components/quotes/ExQuoteForm.jsi/lf    w/lf    attr/             src/components/quotes/HighlightedQuote.js

结论：

我制作的文件有不同的结局。

要更改文件并重置，请执行

git config core.autocrlf falsegit rm --cached -r .git reset --hard

虽然：

在某些项目中，我需要删除存储库并重新启动它。

小开

CR和LF是一组特殊的字符，有助于格式化我们的代码。

CR（/r）将光标放在一行的开头，但不会创建新行。这就是macOS的工作原理。

LF（/n）创建一个新行，但它不会将光标放在该行的开头。光标停留在最后一行的末尾。这就是Unix和Linux的工作方式。

CRLF（/r/f）创建一个新行并将光标放在新行的开头。这是我们在Windows操作系统中看到的。

总结如下：

  1. LF（线路送料）
  • 代表Line Feed
  • 用 /n表示
  • 在代码中创建新行
  • ASCII码是10。
  • 由Unix和其他基于它的操作系统使用。
  1. CR（回车）
  • 代表回程
  • 用 /r表示
  • 将光标放在一行的开头。
  • ASCII码是13。
  • 由macOS及其前身使用。
  1. CRLF（回车和线路送货）
  • 运输返回和线路送料
  • 用 /n/r表示
  • 创建一个新行并将光标放在该新行的开头。
  • LF的ASCII码为10，CR的ASCII码为13。
  • 主要用于Windows OS。

Git默认使用LF。所以当我们在Windows上使用Git时，它会抛出一个警告，比如-“CRLF将被LF替换”，并自动将所有CRLF转换为LF，这样代码就变得兼容了。

注意：别担心……不要把这看作是一个警告，而更多的是一个通知消息。


提交答案