linux - git 用 CRLF 替换 LF

Question

在 Windows XP 机器上运行 git，使用 bash。我从 SVN 导出了我的项目，然后克隆了一个裸存储库。

然后我将导出粘贴到裸存储库目录中，并做了一个：

git add -A

然后我得到一个消息列表，上面写着：

LF 将被 CRLF 取代

这种转换的后果是什么？这是 Visual Studio 中的 .NET 解决方案。

score 1305 · Accepted Answer

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

的概念autocrlf是透明地处理行尾转换。确实如此！

坏消息：需要手动配置值。
好消息：每个 git 安装只能完成一次（也可以按项目设置）。

autocrlf工作原理：

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

这里crlf= win 样式的行尾标记，lf= unix 样式（和 mac osx）。

cr（以上三个选项中的任何一个都不会影响pre-osx ）

此警告何时出现（在 Windows 下）

    – autocrlf=true如果您lf的一个文件中有 unix 样式（= 很少），
    – autocrlf=input如果您crlf的一个文件中有 win 样式（= 几乎总是），
    – autocrlf= false– 从不！

这个警告是什么意思

警告“ LF 将被 CRLF 取代”表示您（拥有autocrlf= true）将在提交签出周期后丢失您的 unix 风格的 LF（它将被 windows 风格的 CRLF 取代）。Git 不希望你在 windows 下使用 unix 风格的 LF。

警告“ CRLF 将被 LF 取代”表示您（拥有autocrlf= input）将在提交签出周期后丢失您的 windows 风格的 CRLF（它将被 unix 风格的 LF 取代）。不要input在windows下使用。

另一种展示如何autocrlf工作的方式

1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

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

file to commit -> repository -> checked out file

怎么修

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

   –“全局”（每个用户）gitconfig 位于~/.gitconfig，另一个
   –“全局”（每个用户）gitconfig 位于$XDG_CONFIG_HOME/git/config或$HOME/.config/git/config–
   “本地”（每个存储库）gitconfig 位于.git/config工作目录中。

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

   – git config --system core.autocrlf false    # per-system 解决方案
   – git config --global core.autocrlf false        # per-user 解决方案
   – git config --local core.autocrlf false            # per-project 解决方案

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

道德（适用于 Windows）：
    - 使用core.autocrlf=true如果您也打算在 Unix 下使用此项目（并且不愿意将您的编辑器/IDE 配置为使用 unix 行尾），
    - 使用core.autocrlf=false如果您打算仅在 Windows 下使用此项目（或者您已将编辑器/IDE 配置为使用 unix 行结尾），
    - 除非您有充分的理由（例如，如果您在 windows 下使用 unix 实用程序或遇到 makefile 问题），否则切勿使用core.autocrlf= ，input

PS安装 git for Windows 时要选择什么？
如果您不打算在 Unix 下使用任何项目，请不要同意默认的第一个选项。选择第三个（Checkout as-is, commit as-is）。您不会看到此消息。曾经。

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

score 811 · Accepted Answer

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

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

您可以通过在上述命令行中添加额外参数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 开发人员，我个人的偏好是将设置保持打开状态。

有关包含“输入”值的更新信息，请参阅https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-config.html 。

score 282 · Accepted Answer

如果您已签出代码，则文件已编入索引。更改 git 设置后，运行：

git config --global core.autocrlf input

你应该刷新索引

git rm --cached -r .

并用重写 git index

git reset --hard

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

资料来源：配置 Git 以处理行尾

score 90 · Accepted Answer

90

git config core.autocrlf false

于 2014-03-21T04:34:58.113 回答

score 52 · Accepted Answer

unix2dos和dos2unix都可以在带有gitbash的 windows 中使用。您可以使用以下命令执行 UNIX(LF) -> DOS(CRLF) 转换。因此，您不会收到警告。

unix2dos filename

或者

dos2unix -D filename

但是，不要在任何现有的 CRLF 文件上运行此命令，那么您将每隔两行得到一个空换行符。

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

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

score 32 · Accepted Answer

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

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

我将 Windows 与 Cygwin 一起使用，在不同时间处理 Windows 和 UNIX 项目。甚至我的 Windows 项目有时也会使用bash需要 UNIX (LF) 行结尾的 shell 脚本。

使用 GitHubcore.autocrlf为 Windows 推荐的设置，如果我签出一个 UNIX 项目（它在 Cygwin 上完美运行 - 或者我正在为我在我的 Linux 服务器上使用的项目做出贡献），文本文件将使用 Windows 签出（CRLF ) 行尾，产生问题。

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

我发现的最佳选择是创建每个存储库的.gitattributes文件。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

设置的东西要多一些，但每个项目只做一次，任何操作系统上的任何贡献者在处理这个项目时都应该不会遇到行尾问题。

score 31 · Accepted Answer

我认为@Basiloungas 的答案很接近但已过时（至少在 Mac 上）。

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

[core]
       autocrlf = input
       safecrlf = false

这 * 将使它显然忽略行尾字符（无论如何对我有用）。

score 21 · Accepted Answer

21

在 vim 中打开文件（例如：）:e YOURFILEENTER，然后

:set noendofline binary
:wq

于 2012-02-21T10:08:21.957 回答

score 18 · Accepted Answer

我也有这个问题。

SVN 不进行任何行尾转换，因此文件以完整的 CRLF 行尾提交。如果您随后使用 git-svn 将项目放入 git 中，那么 CRLF 结尾会一直存在到 git 存储库中，这不是 git 期望找到的状态 - 默认情况下只有 unix/linux (LF) 行结尾入住。

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

据我所知，您的选择是：

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

脚注：如果您选择选项#2，那么我的经验是某些辅助工具（rebase、patch 等）无法处理 CRLF 文件，您迟早会遇到混合了 CRLF 和 LF 的文件（不一致的行结局）。我知道没有办法两全其美。

score 16 · Accepted Answer

16

从 ~/.gitattributes 文件中删除以下内容

* text=auto

将阻止 git 首先检查行尾。

于 2013-01-09T09:36:31.857 回答

score 15 · Accepted Answer

https://web.archive.org/web/20130615060528/http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

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

您可以完全禁用 CRLF 行为，或者通过更改 .gitattributes 文件中的条目来禁用每个文件类型。在我的情况下，我把这个：

-crlf 这告诉 git 忽略所有文件的行尾。并且不会更改工作目录中的文件。即使您将 core.autocrlf 设置为 true、false 或 input。

echo "* -crlf" > .gitattributes

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

这个真的很管用。Git 将尊重混合行尾项目中的行尾，并且不会警告您。

score 14 · Accepted Answer

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

 indent_style = space
 indent_size = 2
 end_of_line = lf    <<====
 charset = utf-8

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

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

（同样的讨论是在 C/++ 中的包含路径中使用 \，这是胡说八道，使用带有斜杠的 #include <pathTo/myheader.h>！，它是 C/++ 标准，所有微软编译器都支持它）。

因此 git 的正确设置是

git config core.autocrlf false

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

score 11 · Accepted Answer

它应该是：

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

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

这张图片应该解释它的含义。

score 10 · Accepted Answer

我对 Windows 上的 git 不太了解，但是...

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

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

总之，您可能不需要对这种转换过于担心。但是，如果您将项目归档为 tarball，其他编码人员可能会喜欢使用 LF 行终止符而不是 CRLF。根据您关心的程度（并且取决于您不使用记事本），如果可以的话，您可能希望将 git 设置为使用 LF 返回：)

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

score 8 · Accepted Answer

确保您已安装最新的 git。
我git config core.autocrlf false在使用 git（版本 2.7.1）时按照上面的方法做了，但它不起作用。
然后它现在可以在升级 git（从 2.7.1 到 2.20.1）时工作。

score 6 · Accepted Answer

在记事本++中打开文件。
转到编辑/EOL 转换。
单击到 Windows 格式。
保存文件。

score 6 · Accepted Answer

OP的问题与windows相关，我无法使用其他人而不去目录甚至在Notepad ++中运行文件，因为管理员不起作用..所以不得不走这条路：

C:\Program Files (x86)\Git\etc>git config --global core.autocrlf false

score 5 · Accepted Answer

在两个不同的操作系统（Linux 和 Windows）中使用“代码”时，CRLF 可能会导致一些问题。我的 python 脚本是在 Linux docker 容器中编写的，然后使用 Windows git-bash 推送。它给了我LF将被CRLF取代的警告。我没有多想，但后来当我开始编写脚本时，它说/usr/bin/env: 'python\r': No such file or directory。现在这\r对你有影响。Windows 使用 "CR" - 回车 - 在 '\n' 顶部作为换行符 - \n\r。这是你可能需要考虑的事情。

score 4 · Accepted Answer

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

点击CRLF右下角：

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

score 3 · Accepted Answer

在 GNU/Linux shell 提示符下，dos2unix 和 unix2dos 命令允许您轻松转换/格式化来自 MS Windows 的文件

score 3 · Accepted Answer

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

添加 --renormalize 有帮助，例如

git add --renormalize .

从文档：

" 对所有跟踪文件重新应用“清理”过程，以强制将它们再次添加到索引中。这在更改 core.autocrlf 配置或文本属性后很有用，以便更正添加了错误 CRLF/LF 行结尾的文件。此选项暗示-u。”

score -1 · Accepted Answer

-1

我有同样的问题，git add . && git reset正确地恢复了所有行尾

于 2021-11-18T15:05:05.213 回答

linux - git 用 CRLF 替换 LF

22 回答 22

Related

Reference