git用CRLF代替LF

Question

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

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

git add -A

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

LF将由CRLF取代

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

Answer 1

这些消息是由于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-style end-of-line marker,lf= unix-style(和mac osx).

(前osx cr未受上述三种选择中的任何一种影响)

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

    - autocrlf= true如果你的lf某个文件中有unix-style (= RARELY),
    - autocrlf= input如果你的crlf某个文件中有win-style (=几乎总是),
    - 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

怎么修

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

   - "全球"(每用户)gitconfig位于~/.gitconfig,另一个
   -在"全球"(每用户)gitconfig $XDG_CONFIG_HOME/git/config或$HOME/.config/git/config和
   - "本地"(每回购)gitconfig在.git/config在工作目录.

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

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

警告
- git config设置可以覆盖gitattributes设置.
- crlf -> lf只有在添加新文件时才会进行转换,crlf回购中已存在的文件不会受到影响.

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

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

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

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

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

Answer 3

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

git rm --cached -r . 

并重写git索引

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

无论unix2dos和DOS2UNIX的是与gitbash窗口可用.您可以使用以下命令执行UNIX(LF) - > DOS(CRLF)转换.因此,你不会收到警告.

unix2dos filename

要么

dos2unix -D filename

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

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

如果由于某种原因你需要强制命令然后使用--force.如果它说无效则使用-f.

Answer 6

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

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

[core]
       autocrlf = input
       safecrlf = false

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

Answer 7

一个GitHub的就行结束文章谈论这个话题时,通常提及.

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

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

使用GitHub推荐core.autocrlf的Windows设置,如果我检查出一个UNIX项目(它在Cygwin上运行得很好 - 或者我正在为我在Linux服务器上使用的项目做贡献),那么用Windows检查文本文件(CRLF) )行结尾,造成问题.

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

我发现的最佳选择是创建per-repository .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

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

Answer 8

在vim中打开文件(例如:) :e YOURFILEENTER,然后

:set noendofline binary
:wq

Answer 9

我也有这个问题.

SVN不进行任何行结束转换,因此提交的文件的CRLF行结尾不变.如果你然后使用git-svn将项目放入git中,那么CRLF结尾会持续存储到git存储库中,这不是git期望找到的状态 - 默认情况下只有unix/linux(LF)行结束入住.

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

据我所知,您的选择是:

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

脚注:如果你选择#2选项,那么我的经验是一些辅助工具(rebase,patch等)不能处理CRLF文件,你迟早会遇到混合了CRLF和LF的文件(不一致的行)结局).我知道无法充分发挥两者的优势.

Answer 10

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

* text=auto

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

Answer 11

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 下使用。

Answer 12

它应该是:

警告:( 如果您检出/或克隆到当前core.autocrlf的另一个文件夹true,)LF将被CRLF取代

该文件将在(当前)工作目录中具有其原始行结尾.

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

Answer 13

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

echo "* -crlf" > .gitattributes 

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

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

Answer 14

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

\n

我的 Python 脚本是在 Linux Docker容器中编写的，然后使用 Windows\' Git\xc2\xa0Bash进行推送。它警告我 LF 将被 CRLF 取代。我没有多想，但后来当我开始编写脚本时，它说：

\n

\n

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

\n

\n

现在这\\r对你来说是一个影响。Windows 在 \'\\n\' 之上使用“CR” - 回车符 - 作为换行符 - \\n\\r。这是你可能需要考虑的事情。

\n

Answer 15

确保你已经安装了最新的 git。
我git config core.autocrlf false在使用 git（2.7.1 版）时按上述方法操作，但没有奏效。
然后它现在在升级 git （从 2.7.1 到 2.20.1）时工作。

Answer 16

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

添加--renormalize有帮助，例如，

git add --renormalize .

从文档中：

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

Answer 17

我刚刚遇到了同样的错误。\n它是在 Windows\xc2\xa010 上安装 NVM NVM后发生的。

\n

在所有级别设置 autoclrf 都不起作用。

\n

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

\n

i/lf    w/crlf  attr/             src/components/quotes/ExQuoteForm.js\ni/lf    w/lf    attr/             src/components/quotes/HighlightedQuote.js\n

\n

结论：

\n

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

\n

要更改文件并重置，请执行以下操作

\n

i/lf    w/crlf  attr/             src/components/quotes/ExQuoteForm.js\ni/lf    w/lf    attr/             src/components/quotes/HighlightedQuote.js\n

\n

虽然：

\n

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

\n

Answer 18

我对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 19

1. 在 Notepad++ 中打开文件。
2. 转到编辑/EOL 转换。
3. 单击 Windows 格式。
4. 保存文件。

Answer 20

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

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