Configuring how line-endings are handled by git
<input type="hidden" title="movePageDialogSearchNoResults" value="There were no pages found containing {0}.">
<input type="hidden" title="movePageDialogSearchResultCount" value="Showing {0}-{1} of {2} pages containing {3}.">
Recommendation
As we are a cross-platform project, it is important that line-endings are handled consistently. Please abide by the general github advice:
Mac & Linux
As the page says, Mac and Linux users do not get to sit this out, and should also configure their git repo to commit Unix-style line endings.
Windows msysgit
If you are using msysgit, you may be presented with these options:
Option two ('Checkout as-is, commit Unix-style line endings') should be used.
Having Problems - Used the Wrong Setting?
A recent checkout of both the&&and the&&would not successfully pass all unit tests. &In particular, asserting the mime-type of the testARofText.ar file (see testArchiveDetection():&) failed (mime-type returned as "text/plain" not "application/x-archive"). &A hex-editor comparison of this file against the same file checked out on a freshly installed laptop showed a difference in line endings for this particular test file (testARofText.ar), suggesting a git line-ending configuration error.
Detailed look at the git configuration showed that one particular setting, core.autocrlf, differed between&set-ups, with the problematic PC having two different values set:
The core.autocrlf&setting tells git to convert newlines to the system's standard when checking out files, and to LF newlines when committing back&[]. &This is the default behaviour when set to true; when set to input, line endings are always LF. &With both set, it seems the system&settings override the global&ones.
The solution is to only set a single core.autocrlf (either in system or global), in this case I opted to remove the system entry:
The files can manually be edited also, and can be found in the following locations:
system: %PROGRAM FILES%/Git/etc/gitconfig
global: & &#126;/.gitconfig
Labels parameters
Enter labels to add to this page:
Looking for a label? Just start typing.linux系统（94）
什么是CRLF和LF为什么要探究CRLF和LF三种方式处理的不同更多参考文献
1、什么是CRLF和LF
CRLF 是&&&&的缩写。中文意思是回车换行。
LF是line feed的缩写，中文意思是换行。
2、为什么要探究CRLF和LF
在学习git软件，安装git到configuring the lien ending conversion时，有三个选项。
a. Checkout Windows-style,commit Unix-style line endings.
b.Checkout as-is,commit Unix-style line endings.
c.Checkout as-is,commit as-is line endings.&
这里面讲到了做两个操作(Checkout,Commit)的三种处理line endings的操作(Windows-style,Unix-style,As-is)。
为什么会出现这三种处理line endings（行尾结束符）呢？在Git的帮助页面给出了很好的解释。
Reference From:/articles/dealing-with-line-endings&
If you're using Git to collaborate with others on GitHub, ensure that Git isproperly configured to handle line endings.
Every time you press return on your keyboard you're actuallyinserting an invisible character called a&line ending. Historically, differentoperating systems
have handled line endings differently.
When you view changes in a file, Git handles line endings in its own way.Since you're collaborating on projects with Git and GitHub, Git mightproduce unexpected results if, for example, you're
working on a Windows machine,and your collaborator has made a change in OS X.
意思很好理解，就不翻译了。重视由于历史的原因，各种不同的操作系统在处理行尾结束符采取了不同的处理方法。而Git和GitHub
3、三种方式处理的不同
CRLF-&Windows-style
LF-&Unix Style
CR-&Mac Style
CRLF表示句尾使用回车换行两个字符(即我们常在Windows编程时使用&\r\n&换行)
LF表示表示句尾，只使用换行.
CR表示只使用回车.
4、在Git中如何转换？
在Git通过下面的命令配置
$git config --global core.autocrlf true
# Configure Git on Windows to properly handle line endings
解释：core.autocrlf是git中负责处理line endings的变量，可以设置三个&#20540;--true,inout,false.
设置成三个&#20540;会有什么效果呢？
If&core.autocrlf&is set to true, that means that any time you add a file to the git repo that git thinks is a text file, it will turn all CRLF line endings to just LF before it stores
it in the commit.。
设置为true，添加文件到git仓库时，git将其视为文本文件。他将把crlf变成lf。【2】
If&core.autocrlf&is set to false, no line-ending conversion is ever performed, so text files are checked in as-is. This usually works ok。【2】
设置为false时，line-endings将不做转换操作。文本文件保持原来的样子。
设置为input时，添加文件git仓库石，git把crlf编程lf。当有人Check代码时还是lf方式。因此在window操作系统下，不要使用这个设置。&
这是参考文献2给的解释希望能帮助大家。&
Yet another way to show how&autocrlf&works
x -& LF -& CRLF
x -& LF -& LF
x -& x -& x
where&x&is either CRLF (windows-style) or LF (unix-style) and arrows stand for
file to commit -& repository -& checked out file
更为复杂的配置命令见网站：https://www.kernel.org/pub/software/scm/git/docs/git-config.html
关于LF和CRLF讨论见：/questions/1967370/git-replacing-lf-with-crlf&
You can also provide a special&--global&flag, which makes Git usethe same settings for line endings across&every&local Git repository on your
【1】/articles/dealing-with-line-endings
【2】/questions/1967370/git-replacing-lf-with-crlf&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：331234次
积分：5638
积分：5638
排名：第3536名
原创：164篇
转载：519篇
(11)(8)(6)(6)(4)(12)(4)(12)(7)(6)(1)(15)(2)(3)(1)(7)(18)(12)(2)(1)(2)(9)(9)(6)(4)(14)(24)(21)(32)(36)(24)(16)(20)(27)(43)(37)(35)(26)(7)(28)(27)(35)(25)(12)(16)(12)写给C语言初学者的话！ - C/C++ - ChinaUnix.net相关信息_学网
||||||||||||在Window上使用Visual Studio编辑Unity3D脚本时常会出现类似如下警告：
警告 1 There are inconsistent line endings in the &#8216;Assets/DubugTest.cs&#8217; script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.
通过Unity3D编辑器创建的脚本文件是以&#8221;LF&#8221;结尾（Unix平台），MonoDevelop IDE创建的也是以“LF”结尾（Unix平台），而直接用Visual Studio创建的文件是以“CR LF”结尾（Windows平台）即由于换行编码不一致导致的。
将脚本文件换行编码统一改为“CR LF”就可以了。
用打开需要修改的文件，然后“文件-&高级保存选项” 行尾选择“Windows (CR LF)”保存即可。