线程结束转换如何在不同操作系统之间使用git core.autocrlf [英] How line ending conversions work with git core.autocrlf between different operating systems

问题描述

关于堆栈溢出以及如何 core.autocrlf 设置的 git 文档，我已阅读了许多不同的问题和解答。 b
$ b

这是我对我读过的内容的理解：

Unix和Mac OSX（pre-OSX使用CR）客户端使用LF

当客户端上的core.autocrlf设置为true时，git仓库始终存储文件在LF行结束格式和客户端文件中的行结尾在客户端（即Windows）使用非LF行结束时的检出/提交时来回转换，无论客户端的行结束文件是什么格式（这与Tim Clem的定义不一致 - 见下面的更新）。

这是一个矩阵，它试图记录核心的'input'和'false'设置相同。带有问号的autocrlf，我不确定行结束转换行为。

我的问题是：

1. 问号应该是什么？


2. 这个矩阵是否正确的用于非问号？

根据答案更新问号，因为共识似乎已经形成。

 
 core.autocrlf值
真实输入false 
 ------------------------------------------------ ---------- 
 commit |兑换           ？ ？ 
 new |到LF（转换为LF？）（不转换？）
 
 commit |转换成        ？没有
存在| LF（转换为LF？）转换
 
结帐|转换成        ？没有
存在| CRLF（无转换？）转换
 
 

我并不真正在寻找各种设置的优点和缺点。我只是在寻找能够清楚说明如何期望git能够在三种设置中进行操作的数据。

-

2012年4月17日更新：阅读 Tim Clem的文章，由JJD在评论中关联，我修改了上表中未知值中的一些值，以及更改checkout存在| true转换为CRLF而不是转换为客户端。以下是他给出的定义，它比我在其他地方看到的更清晰：

这是默认设置，但大多数人都被鼓励立即更改此
。使用false的结果是，Git不会在你的文件中混入
和行结尾。您可以使用LF或CRLF
或CR或其中的一些随机组合来检入文件，而Git并不在意。这
可以使比较难以阅读和合并更困难。在Unix / Linux世界工作的大多数人
都使用这个值，因为他们没有
的CRLF问题，并且当
文件写入到这些文件时，他们不需要Git来做额外的工作对象数据库或写入
工作目录。

core.autocrlf = true

这意味着Git将处理所有文本文件并确保在将该文件写入对象时将
CRLF替换为LF数据库
，当写入正在工作的
目录时，将所有LF都转回CRLF。这是Windows上推荐的设置，因为
确保您的存储库可以在其他平台上使用，而
在您的工作目录中保留CRLF。

core.autocrlf = input
$ b

这意味着Git会处理所有文本文件，并确保在将该文件写入对象
数据库时
CRLF被替换为LF。但是，它不会做相反的事情。当你从对象数据库中读取文件
并将它们写入正在工作的
目录中时，它们将仍然有LF来表示行结束。这个
设置通常在Unix / Linux / OS X上使用，以防止
中的CRLF被写入存储库。这个想法是，如果您从Web浏览器粘贴了
代码，并且意外地将CRLFs放入您的
文件中，那么当您将
写入对象数据库时，Git会确保它们被LF替换。

Tim的文章非常好，我能想到的唯一缺失的就是他假定版本库采用LF格式，这不一定是真实的，特别是对于只有Windows的项目。

比较蒂姆的文章与jmlane迄今为止投票最高的答案，表明了对真实和输入设置和不同意见的完美协议关于错误的设置。

解决方案

最好的解释是 core.autocrlf 作品位于 gitattribute 手册页上，位于 text 属性部分。

这就是 core.autocrlf 似乎正常工作rrently（至少从我知道的v1.7.2开始）：

$ ul

core.autocrlf = true

1. 从存储库签出的只有 LF 字符的文本文件在工作树中标准化为 CRLF ;包含 CRLF 的文件不会被触及


2. 仅包含 LF 字符，在提交回存储库时，从 CRLF 到 LF 进行标准化。

<$ CRLF c $ c> core.autocrlf = input

1. 从存储库检出的文本文件将保留原始EOL字符
   
2. 使用 CRLF 字符的工作树中的文本文件被标准化为 LF 当提交回存储库。

core.autocrlf = false

1. core.eol 指定工作树文本文件中的EOL字符。


2. core.eol = native 默认情况下，这意味着Windows EOL是 CRLF 和* nix EOL在工作树中 LF 。
   
3. 存储库 gitattributes 设置确定EOL字符（缺省是标准化为 LF 字符）。

我o最近刚刚研究了这个问题，我也发现情况非常复杂。 core.eol 设置明确地说明了如何通过git处理EOL字符。




I've read a lot of different questions and answers on Stack Overflow as well as git documentation on how the core.autocrlf setting works.

This is my understanding from what I've read:

Unix and Mac OSX (pre-OSX uses CR) clients use LF line endings.
Windows clients use CRLF line endings.

When core.autocrlf is set to true on the client, the git repository always stores files in LF line ending format and line endings in files on the client are converted back and forth on check out / commit for clients (i.e. Windows) that use non-LF line endings, no matter what format the line endings files are on the client (this disagrees with Tim Clem's definition - see update below).

Here is a matrix that tries to document the same for the 'input' and 'false' settings of core.autocrlf with question marks where I'm not sure of line ending conversion behavior.

My questions are:

1. What should the question marks be?
2. Is this matrix correct for the "non-question marks"?

I'll update the question marks from the answers as consensus appears to be formed.

                       core.autocrlf value
            true            input              false
----------------------------------------------------------
commit   |  convert           ?                  ?
new      |  to LF      (convert to LF?)   (no conversion?)

commit   |  convert to        ?                 no 
existing |  LF         (convert to LF?)     conversion

checkout |  convert to        ?                 no
existing |  CRLF       (no conversion?)     conversion

I'm not really looking for opinions on the pros and cons of the various settings. I'm just looking for data which makes it clear how to expect git to operate with each of the three settings.

--

Update 04/17/2012: After reading the article by Tim Clem linked by JJD in the comments, I have modified some of the values in the "unknown" values in the table above, as well as changing "checkout existing | true to convert to CRLF instead of convert to client". Here are the definitions he gives, which are more clear than anything I've seen elsewhere:

core.autocrlf = false

This is the default, but most people are encouraged to change this immediately. The result of using false is that Git doesn’t ever mess with line endings on your file. You can check in files with LF or CRLF or CR or some random mix of those three and Git does not care. This can make diffs harder to read and merges more difficult. Most people working in a Unix/Linux world use this value because they don’t have CRLF problems and they don’t need Git to be doing extra work whenever files are written to the object database or written out into the working directory.

core.autocrlf = true

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database and turn all LF back into CRLF when writing out into the working directory. This is the recommended setting on Windows because it ensures that your repository can be used on other platforms while retaining CRLF in your working directory.

core.autocrlf = input

This means that Git will process all text files and make sure that CRLF is replaced with LF when writing that file to the object database. It will not, however, do the reverse. When you read files back out of the object database and write them into the working directory they will still have LFs to denote the end of line. This setting is generally used on Unix/Linux/OS X to prevent CRLFs from getting written into the repository. The idea being that if you pasted code from a web browser and accidentally got CRLFs into one of your files, Git would make sure they were replaced with LFs when you wrote to the object database.

Tim's article is excellent, the only thing I can think of that is missing is that he assumes the repository is in LF format, which is not necessarily true, especially for Windows only projects.

Comparing Tim's article to the highest voted answer to date by jmlane shows perfect agreement on the true and input settings and disagreement on the false setting.

解决方案

The best explanation of how core.autocrlf works is found on the gitattributes man page, in the text attribute section.

This is how core.autocrlf appears to work currently (or at least since v1.7.2 from what I am aware):

• core.autocrlf = true
  1. Text files checked-out from the repository that have only LF characters are normalized to CRLF in your working tree; files that contain CRLF in the repository will not be touched
  2. Text files that have only LF characters in the repository, are normalized from CRLF to LF when committed back to the repository. Files that contain CRLF in the repository will be committed untouched.

• core.autocrlf = input
  1. Text files checked-out from the repository will keep original EOL characters in your working tree.
  2. Text files in your working tree with CRLF characters are normalized to LF when committed back to the repository.

• core.autocrlf = false
  1. core.eol dictates EOL characters in the text files of your working tree.
  2. core.eol = native by default, which means Windows EOLs are CRLF and *nix EOLs are LF in working trees.
  3. Repository gitattributes settings determines EOL character normalization for commits to the repository (default is normalization to LF characters).

I've only just recently researched this issue and I also find the situation to be very convoluted. The core.eol setting definitely helped clarify how EOL characters are handled by git.

这篇关于线程结束转换如何在不同操作系统之间使用git core.autocrlf的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！