Question

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

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

git add -A

然后我得到了一条消息列表：

LF将被CRLF取代

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

Answer 1

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

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-style行尾标记，lf = unix-style（和mac osx）。

（前osx cr未受上述三个选项中的任何一个影响）

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

如果您的某个文件（= RARELY）中有unix样式autocrlf，则

- true = lf，
- autocrlf = input如果您的某个文件中有胜利风格的crlf（=几乎总是如此）， - autocrlf = false - 永远不会！

此警告意味着什么

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

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

另一种展示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）中。还有（按以下顺序级联）：

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

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

- 将autocrlf=false添加到系统范围的gitconfig＃per-system解决方案
- git config --global core.autocrlf false＃每用户解决方案
- git config --local core.autocrlf false #per-project solution

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

道德（适用于Windows）：
   - 如果您计划在Unix下使用此项目（并且不愿意将编辑器/ IDE配置为使用unix行结尾），请使用core.autocrlf = true，
   - 如果您计划仅在Windows下使用此项目（或者您已将编辑器/ IDE配置为使用Windows行结尾），请使用core.autocrlf = false，
   - 从不使用core.autocrlf = input除非你有充分的理由（例如，如果你在windows下使用unix实用程序或运行进入makefile问题），

PS 安装适用于Windows的git时要选择什么？
如果您不打算在Unix下使用任何项目，不同意默认的第一个选项。选择第三个（按原样结帐，按原样提交）。你不会看到这条消息。如初。

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

Answer 2

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

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

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

如果将core.autocrlf设置为true，则表示每次将文件添加到git repo中git认为是文本文件时，它都会将所有CRLF行结尾转换为LF，然后再将其存储到提交。无论何时git checkout，所有文本文件都会自动将其LF行结尾转换为CRLF结尾。这允许跨平台开发项目，使用不同的行结束样式而不会提交非常嘈杂的因为每个编辑器都会更改行结束样式，因为行结束样式始终是LF。

这种方便转换的副作用，这就是你所看到的警告，就是如果你最初编写的文本文件有LF结尾而不是CRLF，它将像往常一样用LF存储，但是当以后签出时，它将有CRLF结尾。对于普通文本文件，这通常很好。在这种情况下，警告是“为了您的信息”，但是如果git错误地将二进制文件评估为文本文件，则这是一个重要的警告，因为git会破坏您的二进制文件。

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

我个人的偏好是将该设置保持为开启状态。

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

Answer 3

如果您已经签出了代码，则文件已经编入索引。更改您的git设置后，您应该使用

刷新索引

git rm --cached -r .

并用

重写git index

git reset --hard

https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

Answer 4

git config core.autocrlf false

Answer 5

使用gitbash的Windows中都可以使用 unix2dos 和 dos2unix 。您可以使用以下命令执行UNIX（LF） - ＆gt; DOS（CRLF）转换。因此，你不会收到警告。

unix2dos filename

或

dos2unix -D filename

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

dos2unix -D filename不适用于所有操作系统。请检查this link是否兼容。

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

Answer 6

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

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

[core]
       autocrlf = input
       safecrlf = false

那*会让它忽略行char的结尾（无论如何都为我工作）。

Answer 7

在谈论这个话题时，通常会提到GitHub's article on line endings。

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

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

使用GitHub推荐的Windows core.autocrlf设置，如果我查看一个UNIX项目（它在Cygwin上完美运行 - 或者我可能会对我在我的项目中使用的项目做出贡献Linux服务器），文本文件用Windows（CRLF）行结尾签出，造成问题。

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

我发现的最佳选择是创建每个存储库 .gitattributes 文件。 GitHub article提到它。
该文章的例子：

bash

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

# 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

要设置更多的东西，但每个项目都要做一次，任何操作系统上的任何贡献者在使用这个项目时应该没有线路结尾的麻烦。

Answer 8

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

:set noendofline binary
:wq

Answer 9

我也有这个问题。

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，补丁等）无法处理CRLF文件，您最迟迟于文件结束混合使用CRLF和LF（不一致的行结尾）。我知道无法充分发挥两者的优势。

Answer 10

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

* text=auto

会阻止git在第一时间检查行结尾。

Answer 11

应该是：

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

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

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

Answer 12

http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/

echo "* -crlf" > .gitattributes

在单独的提交中执行此操作，或者当您进行单个更改时，git可能仍会将整个文件视为已修改（取决于您是否更改了autocrlf选项）

这个确实有效。 Git将尊重混合行结束项目中的行结尾，而不是警告你。

Answer 13

我对Windows上的git知之甚少，但是......

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

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

总之，您可能不需要为此转换烦恼太多。但是，如果你将项目归档为tarball，那么编码人员可能会喜欢使用LF线路终结器而不是CRLF。根据您的关注程度（并且取决于您不使用记事本），如果可以，您可能需要设置git以使用LF返回：）

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

Answer 14

在Notepad ++中打开文件。
转到编辑/ EOL转换。
单击“Windows格式”。
保存文件。

Answer 15

OP的问题是与Windows相关的问题，我无法使用其他人而无需访问目录，甚至在Notepad ++中运行文件，因为管理员无法正常工作。所以不得不走这条路：

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

Answer 16

确保已安装最新版本的git。
在使用git（2.7.1版）时，我按照git config core.autocrlf false的要求进行了操作，但是没有用。
然后，当升级git（从2.7.1到2.20.1）时，它现在可以工作。

Answer 17

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路径中使用\，这是胡说，请使用#include 带斜杠！，它是C / ++标准，所有Microsoft编译器都支持它）。

因此git的正确设置是

git config core.autocrlf false

我的信息：忘记诸如dos2unix和unix2dos之类的旧思想程序。在您的团队中确认LF适合在Windows下使用。

Answer 18

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

Answer 19

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

点击右下角的LF：

在顶部的下拉菜单中选择CRLF：

Answer 20

在两个不同的操作系统（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。这是您可能需要考虑的事情。

Answer 21

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

添加 --renormalize 有帮助，例如

git add --renormalize .

来自docs：

<块引用>

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

git用CRLF代替LF

21 个答案: