作者:萌新Jed(李俊德-大连理工大学)
来源:CSDN
原文:https://blog.csdn.net/wq6ylg08/article/details/88761581
一、原因
1、换行符‘\n’和回车符‘\r’
在计算机还没有出现之前,有一种叫做电传打字机(Teletype Model 33)的玩意,每秒钟可以打10个字符。但是它有一个问题,就是打完一行换行的时候,要用去0.2秒,正好可以打两个字符。要是在这0.2秒里面,又有新的字符传过来,那么这个字符将丢失。
于是,研制人员想了个办法解决这个问题,就是在每行后面加两个表示结束的字符。一个叫做“回车”,告诉打字机把打印头定位在左边界;另一个叫做“换行”,告诉打字机把纸向下移一行。
(A)回车符就是回到一行的开头,用符号r表示,十进制ASCII代码是13,十六进制代码为0x0D,回车(return);
(B)换行符就是另起一行,用n符号表示,ASCII代码是10,十六制为0x0A, 换行(newline)。
2、LF和CRLF区别
LF: Line Feed换行
feed v.喂养,供给;将(信息)输入 line feed直译是”将行输入”,再意译”换行”
CRLF: Carriage Return Line Feed 回车换行
Carriage n.马车,火车车厢;运输费用 在carriage return中,carriage译为“车”,return译为“回”
在过去的机械打字机上有个部件叫「字车」(Typewriter carriage),每打一个字符,字车前进一格,打完一行后,我们需要让字车回到起始位置,而“Carriage Return”键最早就是这个作用,因此被直接翻译为「回车」。尽管后来回车键的作用已经不止” 倒回字车”那么简单,但这个译名一直被保留下来。
3.分析问题
这句警告出现的原因:我们在Windows平台下git add任意Windows平台编辑过的代码文本的换行默认都是CRLF,所以一般git add不会出错。但是如果如下的(i)或者(ii)发生了,那我们再进行git add这个LF换行的文件时,会出现这个警告" LF will be replaced by CRLF in …"。
(i)我们的团队成员是Linux/Mac平台并参与了项目的git提交
(ii)我们Windows平台的某些软件会生成换行是LF的代码文本(如李俊德git add的是Webstorm生成的HTML项目中隐藏文件夹.idea中的workspace.xml,这个xml文件换行是LF)
(1)不同操作系统下,处理行尾结束符的方法是不同的:
(A)Windows和Dos下:使用回车(CR)和换行(LF)两个字符来结束一行,回车+换行(CR+LF),即“\r\n”;
(B)Unix和mac下:只使用换行(LF)一个字符来结束一行,即“\n”;
(最早Mac每行结尾是回车CR 即'\r',后mac os x 也投奔了 unix)
(2)Git下处理“换行”(line ending)
core.autocrlf是git中负责处理line ending的变量,可以设置3个值:true,false,input。
(A)设置为true【config --global core.autocrlf true】
当设置成true时,这意味着你在任何时候添加(add)文件到git仓库时,git都会视为它是一个文本文件(text file)。
它将把crlf变成LF。
(B)设置为false【config --global core.autocrlf false】
当设置成false时,line endings将不做转换操作。文本文件保持原来的样子。
(C)设置为input时,添加文件git仓库时,git把crlf编程lf。当有人Check代码时还是lf方式。因此在window操作系统下,不要使用这个设置。
4、此问题的负面影响
格式化与多余的空白字符,特别是在跨平台情况下,有时候是一个令人发指的问题。由于编辑器的不同或者文件行尾的换行符在 Windows 下被替换了,一些细微的空格变化会不经意地混入提交,造成麻烦。虽然这是小问题,但会极大地扰乱跨平台协作。
假如你正在Windows上写程序;又或者你正在和其他人合作,他们在Windows上编程,而你却在其他系统上,在这些情况下,你可能会遇到行尾结束符问题。此问题的全部负面影响如下:
(1)一个直接后果是,Unix/Mac系统下的一个“多行文本”文件在Windows里打开的话,“多行文本”会变成“一行”。(原因:Unix/Mac换行只用了换行符‘\n’,而Windows的换行要求是回车换行符’\r\n’,因此Unix/Mac中的“多行文本”的换行不符合Windows的规则,所以Windows对这些不符合换行规则的“多行文本”全部按照“没有换行”处理,所以导致“多行文本”会变成“一行”)
(2)而Windows里的文件在Unix/Mac下打开的话,在每行的结尾可能会多出一个^M符号。
(3)Linux保存的文件在windows上用记事本看的话会出现黑点。
二、解决办法
作者:幻影浪子
来源:CSDN
原文:https://blog.csdn.net/feng88724/article/details/11600375
一、原因
1、core.safecrlf
Git提供了一个换行符检查功能(core.safecrlf),可以在提交时检查文件是否混用了不同风格的换行符。这个功能的选项如下:
false - 不做任何检查
warn - 在提交时检查并警告
true - 在提交时检查,如果发现混用则拒绝提交
建议使用最严格的 true 选项。
2、core.autocrlf
假如你正在Windows上写程序,又或者你正在和其他人合作,他们在Windows上编程,而你却在其他系统上,在这些情况下,你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行,而Mac和Linux只使用换行一个字符。虽然这是小问题,但它会极大地扰乱跨平台协作。
二、解决办法
Git可以在你提交时自动地把行结束符CRLF转换成LF,而在签出代码时把LF转换成CRLF。用core.autocrlf来打开此项功能,如果是在Windows系统上,把它设置成true,这样当签出代码时,LF会被转换成CRLF:
$ git config --global core.autocrlf true
Linux或Mac系统使用LF作为行结束符,因此你不想 Git 在签出文件时进行自动的转换;当一个以CRLF为行结束符的文件不小心被引入时你肯定想进行修正,把core.autocrlf设置成input来告诉 Git 在提交时把CRLF转换成LF,签出时不转换:
$ git config --global core.autocrlf input
这样会在Windows系统上的签出文件中保留CRLF,会在Mac和Linux系统上,包括仓库中保留LF。
如果你是Windows程序员,且正在开发仅运行在Windows上的项目,可以设置false取消此功能,把回车符记录在库中:
$ git config --global core.autocrlf false