在windows平台进行 git add 时,控制台有时会打印警告 warning: in the working copy of ‘XXX.sh’,LF will be replaced by CRLF the next time Git touches it.
查看了一些资料,大概弄清了 core.autocrlf 配置选项的作用:
git config --global core.autocrlf true
适用于Windows系统,且一般为Windows默认设置,会在提交时对换行符进行CRLF->LF的转换,检出时又会进行LF->CRLF的转换.
我目前在windows平台工作,core.autocrlf 配置为 true,我明白了是因为要进行转换所以会进行告警,但我还是有一些疑惑:
1. 在上面的告警语句中,the next time git touches it 指代什么? working copy 又指什么?
2. 另外,我本地unix格式的文件(我一般是通过tortoisegit 进行commit,push和pull的),经过多次修改提交后格式却没有变化; 但是当我clone一个库后,确实该文件会由unix格式变成了windows格式,为什么?
我又看到一个资料,似乎暂时能解释心中的疑惑了:
问题描述:
windows平台下使用git add,git deploy 文件时经常出现"warning: LF will be replaced by CRLF"的提示:
jedlee@JedsLaptop MINGW64 ~/Desktop/HtmlProject (master)
$ git add .idea
warning: LF will be replaced by CRLF in .idea/workspace.xml.
The file will have its original line endings in your working directory
解决此问题的方案:
(1)如果我们目前是Window平台并出现该警告,啥也别做就行,虽然这个警告难看,但这个警告能保证我们项目团队正常跨系统git操作代码;
因为git的 Windows客户端基本都会默认设置 core.autocrlf=true(我们可通过git config core.autocrlf命令查询我们的Windows上该属性是否默认true. 如不是true,通过config --global core.autocrlf true命令设置该属性为true),而"core.autocrlf=true"有以下3个功能来避免我们出错:
(a)在"把modified的文件git add到暂存区stage"时,Git自动把LF转换成CRLF,并给出那条警告"LF will be replaced by CRLF"
(b)在"把modified的文件由暂存区(stage)提交(commit)到版本库/仓库(repository)“时,Git自动把CRLF转换成LF
(c)在"用 git checkout(检出)切换到指定分支 或 git clone克隆远程版本库"来加载代码时,Git自动把LF转换成CRLF //采出clone时,从远程得到文件果然全部变成了windows格式
提到的那句警告: “IF will be replaced by CRLF in xxx”,这句警告的下面其实还有一句很重要的话: The file will have its original line endings in your working directory. (翻译: “在工作区里,这个文件会保留它原本的换行符”)
(2)如果我们是Linux 或 Mac平台,我们不需要5(1)(c)的功能"在检出或克隆远程版本库时,Git自动把LF转换成CRLF”. 然而当一个CRLF作为行结束符的文件在我们的Linux 或 Mac平台不小心被引入时,你肯定想让 Git 修正. 所以,你可以通过config --global core.autocrlf input 命令把 core.autocrlf 设置成 input 来告诉 Git 在提交(commit)时把CRLF转换成LF,检出(git checkout)时不转换;
(1)+(2): 这样在 Windows 上的检出(checkout)文件中会保留CRLF,而在 Mac 和 Linux 上,以及版本库中会保留LF,从而保证我们项目团队正常跨系统git操作代码;
自己理解的答案:
-
针对第一个疑惑: 当add时,会把"把modified的文件git add到暂存区stage",虽然我不清楚stage是什么,但我想它应该是在本地,它里面的内容会以CRLF结尾,故会进行LF->CRLF的转换; 而"把modified的文件由暂存区(stage)提交(commit)到版本库/仓库(repository)"时,Git自动把CRLF转换成LF; 这个仓库的内容push后应该本地和远方是一致的吧?
warning: in the working copy of ‘XXX.sh’,LF will be replaced by CRLF the next time Git touches it 应该就是在转换之前给出的,the next time git touches it 应该指的是接下来的转换; the working copy of 'XXX.sh’应该是指stage区内的文件;
或者该警告是说: 当git下次检出时,该文档的LF会被CRLF取代?
无论如何,当 autocrlf 为 true 时,对于想在本地保存unix格式的文件来说,应该都不是安全的; -
针对第二个疑惑,可能因为我的项目都是自己使用的缘故,我一般是通过 tortoisegit 进行 git pull 操作,似乎这种操作不会更动原文件吧; 而当我进行 git clone 时,则会从repository中恢复文档,故我原来的unix格式文件会变成windows格式,这也是一个隐患所在;
总结:
对于我上面第二个引用的描述,他给出的解决方案其实适合项目中涉及不同平台的合作开发,故win平台用(1)选项,而linux平台用(2)选项;
而对于我一个人开发的项目(多人开发但只要不跨平台应该也可以),主要还是在win平台编辑,但还需要备份linux平台使用的文件,但会在几个电脑之间进行同步;
那么对于我来说,最好用的选项应该是: autocrlf false (在提交、检出时不会对CRLF/LF换行符进行转换)
它的好处是: 少了换行符的转换,可以加快操作速度; 同时也保证了备份unix格式文件的完整性;
引文链接:
https://blog.csdn.net/Babylonxun/article/details/126598477
https://blog.csdn.net/wq6ylg08/article/details/88761581
原文地址:https://blog.csdn.net/souching/article/details/129331271
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。