在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
当前回答
如果您已经签出了代码,那么文件就已经建立了索引。在更改Git设置后,运行以下命令:
git config --global core.autocrlf input
您应该使用
git rm --cached -r .
并重写Git索引
git reset --hard
注意:这将删除您的本地更改。在你这么做之前考虑把它们藏起来。
来源:配置Git处理行结束符
其他回答
如果您已经签出了代码,那么文件就已经建立了索引。在更改Git设置后,运行以下命令:
git config --global core.autocrlf input
您应该使用
git rm --cached -r .
并重写Git索引
git reset --hard
注意:这将删除您的本地更改。在你这么做之前考虑把它们藏起来。
来源:配置Git处理行结束符
git config core.autocrlf false
在谈到这个话题时,GitHub上一篇关于行尾的文章经常被提到。
我个人使用经常推荐的核心的经验。自专制的配置设置非常复杂。
我在Cygwin中使用Windows,在不同的时间处理Windows和Unix项目。甚至我的Windows项目有时也使用Bash shell脚本,这需要Unix (LF)行结束符。
使用GitHub推荐的核心。如果我签出一个Unix项目(它在Cygwin上工作得很好-或者我正在为一个我在Linux服务器上使用的项目做贡献),文本文件会用Windows (CRLF)行结束符签出,这会产生问题。
基本上,对于像我这样的混合环境,设置全局核心。在某些情况下,任意选择都不能很好地工作。这个选项可以在本地(存储库)Git配置上设置,但即使是这样,对于同时包含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
要设置的东西更多一些,但是每个项目都要设置一次,任何操作系统上的任何贡献者在处理这个项目时都应该不会遇到行结束符的问题。
这些消息是由于core的默认值不正确造成的。在Windows上自定义。
selflf的概念是透明地处理行结束符转换。确实如此!
坏消息:该值需要手动配置。
好消息:每个Git安装只需要执行一次(每个项目设置也可以)。
selff如何工作:
core.autocrlf=true: core.autocrlf=input: core.autocrlf=false:
repository repository repository
^ V ^ V ^ V
/ \ / \ / \
crlf->lf lf->crlf crlf->lf \ / \
/ \ / \ / \
这里crlf = win-style的行尾标记,lf = unix-style(自Mac OS X以来也用于Mac)。
(pre-osx cr不受上述三个选项中的任何一个的影响。)
这个警告什么时候显示(在Windows下)?
如果你的一个文件中有unix风格的lf (= RARELY), 如果你有win-style的crlf在你的一个文件(=几乎总是), - selflf = false - NEVER!
这个警告是什么意思?
警告“LF将被CRLF取代”表示您(拥有自自LF =true)将在提交签出周期后失去unix风格的LF(它将被windows风格的CRLF取代)。Git并不期望你在Windows下使用unix风格的LF。
警告“CRLF将被LF取代”表示您(拥有自自LF =input)将在提交签出周期后失去windows风格的CRLF(它将被unix风格的LF取代)。不要在Windows下使用输入。
这是另一种显示selff如何工作的方法
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的默认值。在Git安装过程中选择自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义自定义。还有(按以下顺序级联):
-“global”(每个用户)gitconfig位于~/。Gitconfig,另一个 -“global”(每个用户)gitconfig $XDG_CONFIG_HOME/git/config或$HOME/配置/ git /配置和 -“local”(per-repo) gitconfig在工作目录的.git/config。
所以,写git config core。在工作目录中查看当前使用的值和
- git配置——系统核心。自专制错误#每系统解决方案 - git配置全局核心。专制错误#每用户解决方案 - git配置——local core。自专制错误#每个项目解决方案
警告
- git配置设置可以被gitattributes设置覆盖。 - CRLF -> lf转换仅在添加新文件时发生,已经存在于repo中的CRLF文件不受影响。
寓意(适用于Windows):
-使用核心。如果你计划在Unix下使用这个项目(并且不愿意将你的编辑器/IDE配置为使用Unix行结束符),自专制语句= true, -使用核心。如果你计划只在Windows下使用这个项目(或者你已经将你的编辑器/IDE配置为使用unix行结束符),自专制语句= false, -永远不要使用核心。除非你有一个很好的理由(例如,如果你在Windows下使用unix实用程序,或者如果你遇到makefiles问题),
安装Git for Windows时选择什么?
如果您不打算在Unix下使用任何项目,请不要同意默认的第一个选项。选择第三个(按原样签出,按原样提交)。你不会看到这条消息。永远。
PPS:我的个人偏好是将编辑器/IDE配置为使用unix风格的结尾,并设置核心。专制到虚伪。
更新(2022)
自2018年以来,git可以根据需要重新规格化回购修复现有的行结束。
如何使Git忽略不同的行结束
http://www.rtuin.nl/2013/02/how-to-make-git-ignore-different-line-endings/(不工作)
您可以完全禁用CRLF行为,或者通过更改.gitattributes文件中的条目来禁用每个文件类型。在我的例子中,我写的是: crlf 这告诉Git忽略所有文件的行结束符。并且不会更改工作目录中的文件。即使你有核心。自专制设置为true, false或输入。
echo "* -crlf" > .gitattributes
在单独提交时执行此操作,否则当您进行单个更改时,Git可能仍然会看到整个文件被修改(取决于您是否更改了selflf选项)。
这个真的有用。Git将尊重混合行结束项目中的行结束符,而不会就此警告您。