git用CRLF代替LF


git replacing LF with CRLF

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

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

1
git add -A

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

LF will be replaced by CRLF

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

相关讨论

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

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

坏消息：需要手动配置值。
好消息：每个git安装应该只进行一次(每个项目设置也可以)。

autocrlf的工作原理：

1
2
3
4
5
6
7
core.autocrlf=true:      core.autocrlf=input:     core.autocrlf=false:

        repo                     repo                     repo
      ^      V                 ^      V                 ^      V
     /        \               /        \               /        \
crlf->lf    lf->crlf     crlf->lf       \             /          \      
   /            \           /            \           /            \

这里crlf = win-style end-of-line marker，lf = unix-style(和mac osx)。

(pre-osx cr未受上述三个选项中的任何一个影响)

该警告何时显示(在Windows下)

＆nbsp;＆nbsp;＆nbsp;＆nbsp; - autocrlf = true如果您的某个文件中包含unix样式lf(= RARELY)，
＆nbsp;＆nbsp;＆nbsp;＆nbsp; - autocrlf = input如果您的某个文件中有win-style crlf(=几乎总是如此)，
＆nbsp;＆nbsp;＆nbsp;＆nbsp; - 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
2
3
1) true:             x -> LF -> CRLF
2) input:            x -> LF -> LF
3) false:            x -> x -> x

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

1
file to commit -> repository -> checked out file

怎么修

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

＆NBSP;＆NBSP; - 位于~/.gitconfig的"global"(每用户)gitconfig，另一个
＆NBSP;＆NBSP; - 位于$XDG_CONFIG_HOME/git/config或$HOME/.config/git/config的"全局"(每用户)gitconfig和
＆NBSP;＆NBSP; - 工作目录中.git/config的"本地"(per-repo)gitconfig。

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

＆NBSP;＆NBSP; - 将autocrlf=false添加到系统范围的gitconfig＆nbsp; ＆NBSP; ＆NBSP; ＆NBSP; #per-system解决方案
＆NBSP;＆NBSP; - git config --global core.autocrlf false＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp; ＆NBSP; ＆NBSP; #per-user解决方案
＆NBSP;＆NBSP; - git config --local core.autocrlf false＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp;＆nbsp; ＆NBSP;＆NBSP;＆NBSP; ＆NBSP; #per-project解决方案

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

道德(适用于Windows)：
＆nbsp;＆nbsp;＆nbsp;＆nbsp; - 如果您计划在Unix下使用此项目(并且不愿意将编辑器/ IDE配置为使用unix行结尾)，请使用core.autocrlf = true，
＆nbsp;＆nbsp;＆nbsp;＆nbsp; - 如果您打算仅在Windows下使用此项目(或者您已将编辑器/ IDE配置为使用unix行结尾)，请使用core.autocrlf = false，
＆nbsp;＆nbsp;＆nbsp;＆nbsp; - 永远不要使用core.autocrlf = input，除非您有充分的理由(例如，如果您在Windows下使用unix实用程序或遇到makefile问题)，

PS安装适用于Windows的git时要选择什么？
如果您不打算在Unix下使用任何项目，请不要同意默认的第一个选项。选择第三个(Checkout as-is，commit as-is)。你不会看到这条消息。永远。

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

相关讨论

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

1
2
$ 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上都是如此。但根据我的经验，我仍然倾向于获得具有混合行结尾的文本文件，最终导致问题。

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

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

相关讨论

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

1
git rm --cached -r .

并重写git索引

1
git reset --hard

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

相关讨论

1
git config core.autocrlf false
相关讨论

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

1
unix2dos filename

要么

1
dos2unix -D filename

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

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

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

相关讨论

我认为@ Basiloungas的答案很接近但过时了(至少在Mac上)。

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

1
2
3
[core]
       autocrlf = input
       safecrlf = false

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

相关讨论

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

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

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

使用GitHub推荐的Windows core.autocrlf设置，如果我查看一个UNIX项目(它在Cygwin上完美运行 - 或者我可能参与我在Linux服务器上使用的项目)，则会检查文本文件Windows(CRLF)行结尾，造成问题。

基本上，对于像我这样的混合环境，将global core.autocrlf设置为任何选项在某些情况下将无法正常工作。此选项可能在本地(存储库)git配置上设置，但即使这对于包含Windows和UNIX相关内容的项目也不够好(例如，我有一个带有一些bash实用程序脚本的Windows项目)。

我发现的最佳选择是创建per-repository .gitattributes文件。 GitHub文章提到了它。
该文章的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
* 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

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

相关讨论

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

1
2
:set noendofline binary
:wq
相关讨论

我也有这个问题。

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的文件(不一致的行)结局)。我知道无法充分发挥两者的优势。

    相关讨论

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

    * text=auto

    将阻止git在第一位检查行结尾。

    相关讨论

    它应该是：

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

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

    这张照片应该解释它的含义。
    enter image description here

    相关讨论

    How to make Git ignore different line endings

    1
    echo"* -crlf"> .gitattributes

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

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

    相关讨论

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

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

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

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

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

    相关讨论

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

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

    确保您已安装最新的git。
    我使用git(版本2.7.1)，如上所述git config core.autocrlf false，但它没有用。
    然后它在升级git时从现在起作用(从2.7.1到2.20.1)。

    相关讨论

  • 在Notepad ++中打开文件。
  • 转到编辑/ EOL转换。
  • 单击"Windows格式"。
  • 保存文件。
    • 相关讨论

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

    点击右下角的CRLF：

    enter image description here

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

    enter image description here

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

    在两个不同的操作系统(Linux和Windows)中使用"代码"时，CRLF可能会导致一些问题。我的python脚本是用Linux docker容器编写的，然后使用Windows git-bash推送。它给了我一个警告，LF将被CRLF取代。我没有多想，但是当我稍后开始编写脚本时，它说/usr/bin/env: 'python
    ': No such file or directory    。现在你的分支是
    。 Windows使用"CR" - 回车 - 在' n'之上作为换行符 -

    。这是你可能需要考虑的事情。