在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
在一台Windows机器上,我使用git add添加了一些文件。 我收到警告说:
LF将被CRLF取代
这种转变的后果是什么?
当前回答
在Vim中,打开文件(例如::e YOURFILEENTER),然后
:set noendofline binary
:wq
其他回答
从~/。gitattributes文件,
* text = auto
将防止Git首先检查行结束符。
在notepad++中打开文件。 进入菜单编辑→EOL转换。 单击Windows格式。 保存文件。
许多文本编辑器允许您更改为LF。请参阅下面的Atom指令。它简单明了。
点击右下角的CRLF:
在顶部的下拉菜单中选择LF:
如果您已经签出了代码,那么文件就已经建立了索引。在更改Git设置后,运行以下命令:
git config --global core.autocrlf input
您应该使用
git rm --cached -r .
并重写Git索引
git reset --hard
注意:这将删除您的本地更改。在你这么做之前考虑把它们藏起来。
来源:配置Git处理行结束符
我也有这个问题。
SVN不执行任何行结束转换,因此提交文件时保留CRLF行结束。如果您使用git-svn将项目放入git中,那么CRLF结束符将持续到git存储库中,这不是git希望自己处于的状态——默认情况是只检入unix/linux (LF)行结束符。
当您在windows上签出文件时,selflf转换会保持文件不变(因为它们已经具有当前平台的正确结尾),但是,决定签入文件是否存在差异的进程会在比较之前执行反向转换,从而将它认为是签出文件中的LF与存储库中的意外CRLF进行比较。
在我看来,你的选择是
Re-import your code into a new git repository without using git-svn, this will mean line endings are converted in the intial git commit --all Set autocrlf to false, and ignore the fact that the line endings are not in git's preferred style Check out your files with autocrlf off, fix all the line endings, check everything back in, and turn it back on again. Rewrite your repository's history so that the original commit no longer contains the CRLF that git wasn't expecting. (The usual caveats about history rewriting apply)
注:如果你选择选项2,那么我的经验是,一些辅助工具(rebase, patch等)不能处理CRLF文件,你迟早会得到混合了CRLF和LF(不一致的行尾)的文件。我不知道有什么办法能两全其美。