前言
使用Git上传文件的时候提示warning: in the working copy of 'xxx', CRLF will be replaced by LF the next time Git touches it
问题分析
warning: in the working copy of 'xxx', CRLF will be replaced by LF the next time Git touches it
表示Git检测到在当前代码库中存在不同的换行符风格,它指出Git在下次处理文件时将替换CRLF(回车+换行)换行符为LF(仅换行)换行符。
我是在使用Hexo上传时出现该问题的,相关文件为文章对应的index.html,因此可能是hexo生成了CRLF换行的html文件导致。
检查问题文件
hexo clean
后重新生成页面,检查问题页面如下,未发现问题,都是LF换行的文件。1
2
3
4
5% od -c index.html
0000000 < ! D O C T Y P E h t m l > \n
0000020 < h t m l > \n < h e a d > \n
...
检查Git配置
先在非git目录下检查了全局配置git config --list
如下,按道理来说没什么问题。
1 | core.autocrlf=input |
core.autocrlf
是Git中的一个配置选项,用于处理跨平台开发时的换行符问题。它用于指定Git在提交和检出文件时是否自动转换换行符的行为。对于多平台协作的项目,特别是在Windows和类Unix系统(如MacOS和Linux)之间进行开发时,配置core.autocrlf
可以确保换行符的一致性,避免在版本控制时频繁更改换行符导致的冲突。
core.autocrlf
有三个可选值:
true
:表示Git会在提交时将CRLF(回车+换行)转换为LF(仅换行),在检出时将LF转换为CRLF。适用于Windows开发者在与类Unix系统的开发者合作时使用。false
:表示Git不会自动转换换行符。适用于在Unix类系统上开发,或者确保文件的换行符保持不变时使用。input
:表示Git会在提交时将CRLF转换为LF,在检出时不做任何转换。适用于在Windows上开发,但在版本库中保留LF换行符的项目。
又到hexo根目录下的.deploy_git
查看了,也是一样,这个配置应该不会出什么问题。
检查Git历史提交
又继续了解了一下,似乎历史提交中出现过CRLF换行的文件也会显示该警告,于是去查看历史提交记录。
1 | git log -p -- filename |
翻看记录,出现红色^M
则是包含CRLF的地方,看到之前在Windows电脑上配置的Gitalk插件是CRLF格式的。
遂修改,解决。其实第一步就能解决了,查找的时候忘记直接搜\r
了…
CR和LF
CR(Carriage Return)和LF(Line Feed)是两个控制字符,通常用于表示文本文件中的行尾。
CR(Carriage Return):
- 在ASCII码中,CR的值为十进制13或十六进制0x0D。
- CR通常表示为
\r
。 - 在早期的打字机和终端设备中,CR用于将打印头或光标移动到行的开头,以便在新的文本输入开始时覆盖之前的内容。
- 在计算机文本中,CR通常用于表示行尾,即在CR之后的内容将从新的一行开始。在某些操作系统中(如Mac OS 9及之前版本),CR被用作行尾符。
LF(Line Feed):
- 在ASCII码中,LF的值为十进制10或十六进制0x0A。
- LF通常表示为
\n
。 - LF在计算机文本中广泛用于表示行尾,即在LF之后的内容将从新的一行开始。在Unix、Linux和现代Mac OS等操作系统中,LF通常被用作行尾符。
在不同的操作系统和文本编辑器中,对于文本文件的行尾表示方式可能不同:
- Unix/Linux/MacOS使用LF(
\n
)作为行尾符。 - Windows使用CRLF(
\r\n
)作为行尾符。
在跨平台开发或处理文本文件时,注意行尾符的差异可能是很重要的。现代的文本编辑器和版本控制系统通常能够识别和处理不同行尾符的文件。
后记
首发于 silencezheng.top,转载请注明出处。