LF将被git中的CRLF所取代 - 这是什么？它很重要吗？ [英] LF will be replaced by CRLF in git - What is that and is it important?

问题描述

可能重复：

git用CRLF替换LF

当我创建一个新的rails应用程序我在git中看到关于LF替换的警告。我做
git init
git add。

然后繁荣！我看到这几乎所有文件都弹出。我通常只是继续前进并构建我的应用程序，并且在对文件进行很多更改后它会消失。

示例：

文件将包含它的原始行尾在你的工作目录中。
警告：LF将被Gemfile中的CRLF替换。

该文件的原始行结束符将位于您的工作目录中。
警告：LF将被Gemfile.lock中的CRLF所取代。

该文件的工作目录中将有其原始行结束符。
警告：LF将在README中被CRLF取代。

LF和CRLF有什么区别？

长远来看，我是否应该关注这个问题，或者忽略它并像往常一样继续前进？

解决方案

在Unix系统中，行的结尾用换行符（LF）表示。在窗口中，一行用回车符（CR）和换行符（LF）表示（CRLF）。当你从gix上传的代码从unix系统上传时，它们只会有一个LF。

如果你想关闭这个警告，在git命令中输入行

  git config core.autocrlf true 
  

如果你想做出明智的决定，git应该如何处理这个问题，阅读文档

这是一段代码

格式和空白

格式和空白问题有些令人沮丧， b $ b许多开发人员在协作时遇到的细微问题，尤其是跨平台
。修补程序或其他
协作工作很容易引入微妙的空白变化，因为
编辑器默默地介绍它们，并且如果您的文件触及
Windows系统，它们的行尾可能会被替换。 Git有几个
配置选项可以帮助解决这些问题。

  core.autocrlf 
  

如果您在Windows上进行编程并且与不是
的人（反之亦然）合作，您可以可能会在
点附近遇到结束性问题。这是因为Windows在文件中同时使用回车符
和换行符作为换行符，而Mac和
Linux系统只使用换行符。这是一个微妙的但是
令人难以置信的跨平台工作事实;
Windows上的许多编辑默默地用CRLF替换现有的LF风格的行结尾，或者
在用户点击回车键时插入两行结尾字符。

当
向索引添加文件时，Git可以通过将CRLF行结束符自动转换为LF来处理此问题，反之亦然，当它将代码
签出到文件系统中时。您可以使用
core.autocrlf设置打开此功能。如果您在Windows机器上，请将其设置为true
- 当您签出代码时，会将LF结尾转换为CRLF：

  $ git config --global core.autocrlf true 
  

如果你在Linux或者使用LF行尾的Mac系统，那么您
不希望Git在您签出文件时自动转换它们;
但是，如果一个带有CRLF结尾的文件意外地被引入，
，那么你可能希望Git修复它。您可以通过将core.autocrlf设置为
输入来告诉Git在提交时将CRLF转换为
LF，而不是其他方式：

  $ git config --global core.autocrlf input 
  

这个设置应该离开你在Windows checkout中使用CRLF结尾，
但在Mac和Linux系统以及存储库中使用LF结尾。

如果你是一位Windows程序员， -only项目，那么你
可以关闭这个功能，通过设置config值为false来记录
仓库中的回车信息：

 $ git config --global core.autocrlf false 
  

Possible Duplicate:
git replacing LF with CRLF

When I create a new rails application I'm seeing a warning in git about LF replacement. I do git init git add .

and then boom! I see this pop up for almost all files. I usually just keep going and build my application and it disappears after many changes to files.

Example:

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in Gemfile.lock.

The file will have its original line endings in your working directory. warning: LF will be replaced by CRLF in README.

What's the difference between LF and CRLF?

Should I be concerned about this in the long run or just ignore it and keep going as I usually do?

解决方案

In Unix systems the end of a line is represented with a line feed (LF). In windows a line is represented with a carriage return (CR) and a line feed (LF) thus (CRLF). when you get code from git that was uploaded from a unix system they will only have an LF.

If you want to turn this warning off, type this in the git command line

git config core.autocrlf true

If you want to make an intelligent decision how git should handle this, read the documentation

Here is a snippet

Formatting and Whitespace

Formatting and whitespace issues are some of the more frustrating and subtle problems that many developers encounter when collaborating, especially cross-platform. It’s very easy for patches or other collaborated work to introduce subtle whitespace changes because editors silently introduce them, and if your files ever touch a Windows system, their line endings might be replaced. Git has a few configuration options to help with these issues.

core.autocrlf

If you’re programming on Windows and working with people who are not (or vice-versa), you’ll probably run into line-ending issues at some point. This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas Mac and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true

If you’re on a Linux or Mac system that uses LF line endings, then you don’t want Git to automatically convert them when you check out files; however, if a file with CRLF endings accidentally gets introduced, then you may want Git to fix it. You can tell Git to convert CRLF to LF on commit but not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

This setup should leave you with CRLF endings in Windows checkouts, but LF endings on Mac and Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you can turn off this functionality, recording the carriage returns in the repository by setting the config value to false:

$ git config --global core.autocrlf false

这篇关于LF将被git中的CRLF所取代 - 这是什么？它很重要吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！