我正在从存储库中检出我是Mac和Linux中唯一的Windows用户。我的IDE在我的Windows机器上运行,代码被推送到VM。代码不会同步回主机。当我准备在我的Windows主机上添加/提交时,我收到warning: LF will be replaced by CRLF
消息。
这些是我的Git设置:
core.symlinks=false
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
diff.astextplain.textconv=astextplain
rebase.autosquash=true
credential.helper=manager
core.editor='C:/Program Files/Notepad++/notepad++.exe' -multiInst -nosession
core.filemode=false
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
我不确定为什么core.filemode=false
被列出两次。
我有理由在Windows上收到此警告吗?我在我的设置中做了什么蠢事(完全有可能)?或者,这在这种情况下是否有意义,如果是,为什么?
答案 0 :(得分:3)
Git有两个地方可以控制换行:
在你的Git设置中你有core.autocrlf = true。这意味着你告诉Git将结束的行改为CRLF。您可以更改此设置以查看Git是否停止尝试更改行结尾。
git config --global core.autocrlf input
更好的方法可能是在.gitattributes文件中设置正确的行结尾。这将提交到根目录中的存储库,它将覆盖用户的个人设置。这可确保所有提交到仓库的用户都具有正确的行结尾。因为听起来你正在开发基于* nix的项目,所以将行结尾设置为换行可能是谨慎的。在.gitattribute文件中,你可以有这样的东西。
# Set all files to have LF line endings
* text eol=lf
此链接提供了您可以在文件中设置的选项的更详细说明:https://help.github.com/articles/dealing-with-line-endings/
编辑1:我认为我从实际的Git文档中添加了这个:https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration
core.autocrlf
如果您在Windows上编程并与人合作 谁不是(或反之亦然),你可能会遇到行尾 某些问题。这是因为Windows同时使用了a 回车符和换行符的换行符 文件,而Mac和Linux系统只使用换行符。 这是跨平台工作的一个微妙但令人讨厌的事实; Windows上的许多编辑器默默地替换现有的LF风格的线路 使用CRLF结尾,或在用户时插入两个行结束字符 点击回车键。
Git可以通过将CRLF行结尾自动转换为LF来处理此问题 您将文件添加到索引,反之亦然,当它检出代码时 到您的文件系统。您可以使用。打开此功能 core.autocrlf设置。如果您使用的是Windows计算机,请将其设置为true - 当您检查代码时,这会将LF结尾转换为CRLF:
$ git config --global core.autocrlf true
如果您使用的是Linux或Mac 使用LF行结尾的系统,那么你不希望Git 签出文件时自动转换它们;但是,如果一个 文件与CRLF结尾不小心被引入,然后你可能想要 Git来解决它。您可以告诉Git在提交时将CRLF转换为LF 通过将core.autocrlf设置为输入而不是相反:
$ git config --global core.autocrlf input
这个设置应该离开你 在Windows签出中使用CRLF结尾,但在Mac和Linux上使用LF结尾 Linux系统和存储库。
如果您是Windows程序员,只执行Windows项目,那么您 可以关闭此功能,在中记录回车 通过将配置值设置为false来存储库:
$ git config --global core.autocrlf false
答案 1 :(得分:0)
有一个普遍的误解,在Windows上,config.autocrlf=true
总是使Git在签出文件时使用CRLF行尾。但是,如果您仔细阅读Git documentation,则会发现:
[设置
config.autocrlf=true
]不会强制对文本文件进行规范化,但是会确保您添加到存储库中的文本文件在添加时将其行尾规范化为LF,并且已经进行了规范化在存储库中保持规范化。
换句话说,如果文件在提交到存储库时已经被分类为文本文件,则Git仅在签出文件时使用CRLF。默认情况下,Git不会自动将文件分类为文本。是的,这令人难以置信,但它是一项安全预防措施,因此默认情况下,Git绝不会破坏它认为是文本的二进制文件。
我们可以通过告诉Git确定文件是否为文本来防止此问题。下列任一选项均有效:
在Git属性文件中,为所有文件输入set the "text" attribute to "auto"。这会将Git配置为自动确定文件是否为文本。您可以为每个参与者(默认位置:$HOME/.config/git/attributes
)设置一次,也可以为每个仓库(.gitattributes
)设置一次。
如果您使用的是Windows计算机,请set "core.autocrlf" to "true"。与#1相同,但也将core.eol
设置为crlf
,这就是为什么只应在Windows系统上进行的原因。
如果您有一个回购程序,其文件未归类为文本,则在每次提交对这些文件的更改时,可能会收到一堆LF will be replaced by CRLF
警告。要彻底解决此问题,请在执行上述Git配置之后,对所有文件运行unix2dos
(在Git Bash中使用find . -exec unix2dos {} \;
或equivalent Windows command),然后提交它们。这些文件将立即全部重新分类为文本,您将停止收到警告,并且在工作目录中使用CRLF行尾也将受益。远程存储库仍将使用LF行尾,但是具有上述配置的Windows系统上将来的存储库克隆将按预期在本地使用CRLF行尾。