git 用 CRLF 替换 LF

git add -A

答案

这些消息是由于 Windows 上core.autocrlf默认值不正确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 风格的行尾标记, lf = Unix 风格(和 mac osx)。

(对于以上三个选项,osx 之前的cr不受影响)

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

autocrlf = true如果其中一个文件(= 很少)中包含 unix 样式的lf
- autocrlf = input ,如果你有赢风格crlf在文件中的一个(= 几乎总是)
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 -> 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中的 “本地”(按仓库)gitconfig。

因此,在工作目录中编写git config core.autocrlf来检查当前使用的值并

–将autocrlf=false添加到系统范围的 gitconfig#每个系统的解决方案
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
- 除非有充分的理由( 例如,如果您在 Windows 下使用 Unix 实用程序或遇到 makefile 文件问题),否则请勿使用core.autocrlf = input

PS 为 Windows 安装 git 时要选择什么?
如果您不打算在 Unix 下使用任何项目, 则不要同意默认的第一个选项。选择第三个( 按原样签出,按原样提交 )。您不会看到此消息。曾经

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

Git 有三种处理行尾的方式:

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

您可以通过在上面的命令行中添加其他参数truefalse来设置要使用的模式。

如果将core.autocrlf设置为 true,则意味着core.autocrlf将文件添加到 git 认为是文本文件的 git repo 中时,它将所有 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 设置后,您应该使用刷新索引

git rm --cached -r .

并用

git reset --hard

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

git config core.autocrlf false

unix2dosdos2unix均可在带有 gitbash 的 Windows 中使用。您可以使用以下命令执行 UNIX(LF)-> DOS(CRLF)转换。因此,您将不会收到警告。

unix2dos filename

要么

dos2unix -D filename

但是,请不要在任何现有的 CRLF 文件上运行此命令,否则每隔两行就会得到空的换行符。

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

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

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

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

[core]
       autocrlf = input
       safecrlf = false

* 会使它显然忽略行末字符(无论如何对我来说还是有用的)。

在谈论此主题时,通常会提到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 config 上设置此选项,但是对于同时包含与 Windows 和 UNIX 相关的内容的项目(例如,我有一个带有bash实用程序脚本的 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

设置起来还有很多事情,但是每个项目要做一次,并且在使用此项目时,任何 OS 上的任何贡献者在行尾都应该没有问题。

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

:set noendofline binary
:wq

我也有这个问题。

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,那么我的经验是某些辅助工具(变基,修补程序等)无法处理 CRLF 文件,并且您迟早会使用 CRLF 和 LF 混合文件(行不一致)结尾)。我不知道如何同时兼顾两者。

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

* text=auto

将阻止 git 首先检查行尾。