git:autocrlf = true core.eol = native vs autocrlf = input [英] Git: autocrlf=true core.eol=native vs autocrlf=input

问题描述

有人可以解释一下设置之间的区别吗?

core.autocrlf = true

core.eol = native

和

core.autocrlf = input

我们同时使用这两种情况吗?

解决方案

何时[我们]应该使用[这两个设置]?

我的偏好是从不.另一方面，我也不在Windows上工作. :-)但是，如果您仔细阅读以下所有内容，将会发现如果我这样做了，我仍然会说从不". (即使您共享一些不允许在其中创建.gitattributes文件的上游存储库，也可以在自己的克隆中使用每个存储库$GIT_DIR/info/attributes文件.)

[有什么区别?]

要达到不同，我们需要首先注意:

• 什么是转化? Git可以进行哪些转换?
• Git何时可以进行转化? Git何时 会进行转化?
• Git如何确定文件为文本"?

转换，输入和输出:清洁和涂抹

第一部分非常简单，尽管它为新手提供了自己的绊脚石. Git可以执行您想要的任何转换，因为它具有Git所说的干净过滤器和污迹过滤器.

干净过滤器是您自己写的一种转换，是的！您可以使用git add或Git将文件从工作树复制到索引时应用Git.相等的.也就是说，假设您有一个文件检出到您的工作树中，然后对其进行编辑或完全替换，或者在该文件上运行一些程序对其进行更改.您可能要提交该文件的新版本.因此，您必须运行git add path将文件从工作树复制回索引. (请记住，Git是根据 index 中的内容而不是工作树中的内容进行新提交的.这就是为什么您始终始终必须git add进行文件提交的原因:Git不会自动从工作树复制到索引.)

无论何时运行git add file，Git都会清理"文件.这就是输入转换.

相反，您可以编写自己的过滤器过滤器，当Git 超出索引(进入索引，进入工作)时，您可以执行此操作来归档数据-树).由于Git内部的所有文件(包括准备将其复制到 next 提交中的索引中的文件)都采用某些特殊的，内部的，仅Git的格式，因此每个文件必须转换为所有常规计算机程序都可以处理的普通格式.每当您将文件提取到工作树时，Git都会在出路时涂抹"(脏污)该文件.那是一个输出转换.

Git有时会执行输入转换，而没有实际将文件复制到索引中:特别是，如果您运行的git diff必须将工作树文件与同一文件的索引或已提交副本进行比较，则内部存储库中的一个已被清理"，而工作树中的一个被弄脏"和脏污".在它们都处于相同状态之前，无法对其进行比较，因此Git将在进行比较之前清理"工作树.

内置行尾转换

Git有两个内置的转换.一种是在清理时使用的，即当文件从工作树复制到Git(进入索引)时使用.这一行将CRLF行尾替换为仅换行符，Linux风格的行尾.另一种是在涂抹时使用，即从Git中复制文件时使用.这个用...替换 something .

这是core.eol出现的地方.您可以让Git用CRLF替换换行符，如果您使用的是Windows，并且您有要求该行以CRLF结尾的程序，则可能需要使用Git替换换行符.还与在Linux上工作的人一起工作，这些人要求行以仅LF的换行符结尾.

或者，您可以让Git用仅LF替换换行符...除了不是替换之外，因为换行符 是换行符"LF" .称它为替代品有点愚蠢.

您可以让Git根据您的系统选择结尾，以便将core.eol设置为native的一种配置在 Linux 和 Windows上均可使用

Git有点偷偷摸摸:当要用LF替换" LF(毕竟这不是替代品)时，它往往无能为力-甚至不检查任何东西-因此运行得更快.似乎您可能永远不会注意到这一点，只是core.safecrlf设置要求Git检查事物. safecrlf涉及一些猜测，并且过分保护，如果您要进行转换，则可以设置.gitattributes设置，这样就不会损坏任何二进制文件.

二进制文件:Git如何确定文件是文本?

有些文件(例如.jpg图片)只是不是文本，并且从不不应在中修改任何任何数据文本式"的方式.它们需要使用图像处理代码进行操作，而不是使用文本编辑器或笨拙的工具行Git的内置转换来进行操作.因此，Git需要一种方法来区分 text 文件和 non-text 或 binary 文件，该文件应应用这些行尾转换./p>

如果您不告诉Git哪些文件，则必须猜测. Git用来猜测.jpg或.txt扩展名的方法是 not ，例如，这不适用于名为README的文件.取而代之的是，Git查看存储在文件中的数据，并根据它是看起来像文本的"还是看起来像二进制的"进行猜测.

您可以想象，这个猜谜游戏并不完美.它可能对您有用，但是如果不起作用，您可以并且应该 tell Git哪些文件是哪个.为此，您可以创建一个名为.gitattributes的文件.在.gitattributes中，您可以将特定文件名(如README)或路径名模式(如*.txt和*.jpg)列出为绝对文本"或绝对二进制".您可以使用text或-text进行此操作.您还可以告诉Git:猜测！您可以通过auto来做到这一点:

*.txt   text
*.jpg   -text
guess   auto

如果可以帮助，则永远不要使用auto.

如果您从未让Git进行任何转换，则不必这样做. 告诉Git哪些文件是文本文件，哪些是二进制文件是很重要的一点.确保Git正确执行了转换，并且只有在进行转换时才需要这样做.因此，如果您避开Windows，则不必创建.gitattributes并列出文件.无论如何，创建它并没有真正的伤害，但是如果您创建了它，则应尝试使其覆盖所有文件，以使Git不必猜测.

现在我们已经了解了所有这些，我们可以了解文档了

考虑到以上几点，我们可以通过咨询core.autocrlf的作用. rel ="noreferrer"> git config文档，然后向下滚动至core.autocrlf描述:

将此变量设置为"true"与设置text相同 在所有文件上将属性设置为自动"，将core.eol属性设置为"crlf".设置 如果您想在工作中使用CRLF行结尾，则为true 目录，并且存储库具有LF行结尾.这个变量可以 设置为 input ，在这种情况下将不执行输出转换.

换句话说，core.autocrlf=true就像在所有文件上使用auto设置一样，这是您永远都不要做的.因此，您永远不要使用此功能. :-)它可以正常工作，但我不建议这样做:创建一个正确的.gitattributes并在其中列出所有文件，以免您在玩猜谜游戏. 一旦您的.gitattributes文件列出了所有内容，core.autocrlf=true就不会生效，因为.gitattributes设置会覆盖它.

使用core.autocrlf=input告诉Git进行相同的猜测，但也仅进行输入转换(例如在git add清理期间).我本人对此设置没有用，也无法真正想象出任何一个好主意的情况.可能存在这种情况，但是如果您要进行转换，则应明确指定它们；并且在.gitattributes文件中正确指定了它们之后，双向进行转换似乎更有意义，因此无需使用input.

至于将core.eol设置为native，文档声称这是默认设置(这似乎是最佳选择)，因此除了覆盖其他配置文件的错误选择外，没有其他理由非默认设置.

Can somebody explain what is the difference between settings:

core.autocrlf = true

core.eol = native

and

core.autocrlf = input

When we use both cases?

解决方案

When [should] we use [either of these settings]?

My preference is never. On the other hand, I also don't work on Windows. :-) However, if you read through all of the text below, you will see that if I did, I'd still say "never". (Even if you are sharing some upstream repository in which you're not allowed to create a .gitattributes file, you can use the per-repository $GIT_DIR/info/attributes file in your own clone.)

[What's the difference?]

To get to the difference, we need to first note:

• What are conversions? What conversions can Git do?
• When can Git do conversions? When will Git do conversions?
• How does Git decide that a file is "text"?

Conversions, input and output: cleaning and smudging

The first part is pretty straightforward, although it presents its own stumbling block for newbies. Git can do any conversions you want, because it has what Git calls clean filters and smudge filters.

A clean filter is a conversion you—yes, you!—can write for yourself, that Git will apply when you copy a file from the work-tree to the index using git add or equivalent. That is, suppose you have a file checked out into your work-tree, and you edit it, or replace it entirely, or run some program over it that makes changes to it. You probably want to commit the new version of that file. So you must run git add path to copy the file from the work-tree, back into the index. (Remember that Git makes new commits from whatever's in the index, not from what's in the work-tree. This is why you keep having to git add your files all the time: Git doesn't automatically copy from work-tree to index.)

Whenever you run git add file, Git will "clean" the file on the way in. That's an input conversion.

Conversely, you can write your own smudge filter, which is something you do to file data when it comes out of Git (out of the index, into your work-tree). Since all files inside Git, including those in the index where they're ready to be copied into the next commit, are in some special, internal, Git-only format, every file must be converted into the normal format that all your regular computer programs can deal with. Whenever you extract the file to the work-tree, Git will "smudge" (dirty up) the file on the way out. That's an output conversion.

Git will occasionally do an input conversion without actually copying the file into the index: in particular, if you run a git diff that has to compare a work-tree file to an index or committed copy of the same file, the one that's inside the repository has already been "cleaned", while the one that's in the work-tree is all "smudged" and "dirty". They can't be compared until they are both in the same state, so Git will "clean up" the work-tree one before doing the diff.

The built-in line-ending conversions

Git has two built-in conversions. One is meant to be used when cleaning, i.e., when files get copied from the work-tree into Git (into the index). This one replaces CRLF line endings with newline-only, Linux-style, line endings. The other is meant to be used when smudging, i.e., when copying files out of Git. This one replaces newline-only Linux-style line endings with ... well, something.

This "something" is where core.eol comes in. You can have Git replace newlines with CRLF, which you might want if you're on Windows and you have programs that demand that lines end with CRLF, but you're also working with people who work on Linux which demands that lines end with LF-only newline style endings.

Or, you can have Git replace newlines with LF-only ... except that's not a replacement, because a newline is a line-feed "LF" character. It's a bit silly to call this a replacement.

You can have Git choose the ending based on your system, so that one configuration, with core.eol set to native, works on both Linux and Windows.

Git is a little sneaky: when it is going to "replace" LF with LF (which isn't a replacement after all) it tends to do nothing—not even to inspect anything—and hence go faster. It seems like you might never notice this, except that the core.safecrlf setting requires that Git inspect things. This safecrlf thing involves some guessing, and is meant to be overprotective and get you to set .gitattributes settings if you're doing conversions at all, so that you don't damage any binary files.

Binary files: how does Git decide that a file is text?

Some files, like .jpg images for instance, are simply not text and should never have any of their data modified in "text-ish" ways. They need to be manipulated with image-manipulation code, not with a text editor, or a clumsy tool line Git's built-in conversions. Git therefore needs a way to distinguish text files, which should get these line-ending conversions applied, from non-text or binary files.

If you don't tell Git which files are which, it is going to have to guess. The method Git uses to guess is not to look at the .jpg or .txt extension—this doesn't work on a file named README, for instance. Instead, Git looks at the data stored in the file, and guesses based on whether it "looks text-ish" or "looks binary".

As you can imagine, this guessing game is not perfect. It may work for you, but if it doesn't, you can and should tell Git which files are which. You do this by creating a file named .gitattributes. In .gitattributes, you can list particular file names like README, or path name patterns like *.txt and *.jpg, as being "definitely text" or "definitely binary". You do this with text or -text. You can also tell Git: guess! You do this with auto:

*.txt   text
*.jpg   -text
guess   auto

You should never use auto if you can help it.

You don't have to do this if you never have Git do any conversions. The point of telling Git which files are text and which are binary is to make sure that Git does the conversions correctly, and you only need to do this if you are doing conversions. So if you avoid Windows, you don't have to create a .gitattributes and list your files. It doesn't really hurt to create it anyway, but if you do create it, you should try to have it cover all your files, so that Git does not have to guess.

Now that we know all this, we can understand the documentation

With the above in mind, we can see what core.autocrlf does by consulting the git config documentation and scrolling down to the core.autocrlf description:

Setting this variable to "true" is the same as setting the text attribute to "auto" on all files and core.eol to "crlf". Set to true if you want to have CRLF line endings in your working directory and the repository has LF line endings. This variable can be set to input, in which case no output conversion is performed.

In other words, core.autocrlf=true is like using the auto setting on all files, which is something you should never do. So you should never use this. :-) It can work, but I would not recommend it: create a proper .gitattributes and list all your files there, so that you are not playing guessing games. Once your .gitattributes file lists everything, core.autocrlf=true has no effect, because the .gitattributes setting overrides it.

Using core.autocrlf=input tells Git to do the same guessing, but also to do only input conversions (during the git add cleaning for instance). I have no use for this setting myself, and cannot really imagine any situation in which it's a good idea. Such a situation might exist, but if you're going to do conversions at all, you should specify them explicitly; and once you have specified them correctly in your .gitattributes file, it seems to make more sense to do conversions in both directions, so there's no reason to use input.

As for setting core.eol to native, the documentation claims that this is the default (and it seems like the best choice), so there is no reason to bother, other than to override someone other configuration file's poor choice of a non-default setting.

这篇关于git:autocrlf = true core.eol = native vs autocrlf = input的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！