什么是“签出代码”在git文档中是否表示行尾？ [英] What does "check out code" mean in git documentation for line endings?

问题描述

我真的很困惑，在下面的页面中，check out code的意思是： https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code

< blockquote>

如果您在Windows计算机上，请将其设置为true - 当您签出代码时，会将LF结尾转换为CRLF：

这是否意味着您添加文件时？因为无论何时将 core.autocrlf 从输入更改为 true 反之亦然，我在添加文件时看到的差异（检出是指添加？）：

 > git config --global core.autocrlf true 
 
> git add crlf-file.md 
 
> git add lf-file.md 
警告：LF将被lf-file.md中的CRLF所取代。 
该文件将在工作目录中具有其原始行结尾。 
 
> git config --global core.autocrlf input 
 
> git add crlf-file.md 
警告：crlf-file.md中的CRLF将被替换为LF。 
该文件将在工作目录中具有其原始行结尾。 
> git add lf-file.md 
  

解决方案

试图回答潜在的问题，这似乎确实如此：如果checkout意味着 git checkout ，为什么我会在期间收到这些消息？ git add ？）

关于这个的文档有点草率，可能是故意的，因为完全正确的细节有些模糊。为了在概念层面上理解它，你应该将行结束修改看作更一般的 smudge 和 clean 过滤的一部分（因为这实际上是如何实现的）。

在Git中，您目前可以使用的每个文件同时存在于三个位置：

  HEAD提交工作树的索引
 --------------- --------- ---- --------- 
 README.md README.md README.md 
 file.txt file.txt file.txt 
  

除了全部提交在任何时候都是只读的，文件可以在各个方向上复制。因此，您可以从HEAD提交复制到索引中，或从索引复制到工作树中。您也可以从工作树复制到索引中。

（您也可以从索引创建一个新的 提交。旧的HEAD单独提交，新的提交变成HEAD提交，所以在做了一个新的提交后，HEAD提交和索引匹配，这不是因为我们修改了任何提交;我们可以可以这是因为我们已经添加了一个新的提交，由索引创建，然后我们停止调用旧的提交HEAD，并将新的提交为HEAD。）

请注意，索引位于HEAD和工作树之间。为了将任何文件从HEAD复制到工作树，它必须首先通过索引。为了从工作树进行新的提交，每个新文件都必须通过索引。因此，索引/工作树转换是清理和弄脏的地方。一个文件意味着它准备好提交。例如，此清洁过程可将CRLF行尾转换为仅LF行行尾。 或者，使用 ident 过滤器，您可以取消许多替换，或者编写你自己的过滤器来做任何事情。对于涂抹文件意味着准备在工作树中进行编辑和/或使用。例如，这可以将仅限LF的行结尾转换为CRLF结尾。与清理过程一样，您可以使用 ident 过滤器或您自己的过滤器驱动程序来执行任何您想要的操作。 Git LFS 使用这些驱动程序交换简短引用和整个文件内容。

因此，确切答案是在将文件复制到索引或从索引中复制的过程中应用了行结束转换。最常见的是这两个：

• git add 从工作树复制到索引。
  
• git checkout 从提交到索引然后到工作树或从索引直接提取到工作树to work-tree。

只有在这些时候，任何这些CRLF-to-LF或发生LF到CRLF转换。但Git有额外的代码，试图直观稍后做这些转换是否会导致对现有已提交数据的更改，即使它尚未完成。 代码会给你看到的警告信息：

 警告：LF将被替换为CRLF ... 
警告：CRLF将被LF替换... 
  

这些警告出来，如果你启用安全crlf选项。因为它们来自不同的代码，所以一切都会变得非常混乱。

I'm really confused what "check out code" means in the following page: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code

If you’re on a Windows machine, set it to true – this converts LF endings into CRLF when you check out code:

Does it mean when you add files? Because whenever I change core.autocrlf from input to true and vice-versa, the differrence I see in when I add the files (does "check out" mean "add"?):

> git config --global core.autocrlf true

> git add crlf-file.md

> git add lf-file.md
 warning: LF will be replaced by CRLF in lf-file.md.
 The file will have its original line endings in your working directory.

> git config --global core.autocrlf input

> git add crlf-file.md
  warning: CRLF will be replaced by LF in crlf-file.md.
  The file will have its original line endings in your working directory.
> git add lf-file.md

解决方案

(Note: I'm trying to answer the underlying question, which seems to really be: If checkout means git checkout, why do I get these messages during git add?)

The documentation on this is all a little bit sloppy, possibly on purpose because the exactly-correct details are somewhat obscure. To understand it well on a conceptual level, you should view line-ending-modification as part of the more general smudge and clean filtering (since this is in fact how it's implemented).

In Git, every file you can work with at the moment exists simultaneously in three places:

the HEAD commit      the index       the work-tree
---------------      ---------       -------------
README.md            README.md       README.md
file.txt             file.txt        file.txt

Files can be copied in various directions, except that all commits are read-only at all times. So you can copy from the HEAD commit into the index, or from the index into the work-tree. You can also copy from the work-tree into the index.

(You can also make a new commit from the index. This leaves the old HEAD commit alone, and the new commit becomes the HEAD commit. So after making a new commit, the HEAD commit and the index match. This is not because we modified any commit; we can't do that. It's because we have added a new commit, made from the index, and then we stop calling the old commit the HEAD and call the new one the HEAD instead.)

Note that the index sits "in the way" between HEAD and work-tree. In order to copy any file from HEAD to work-tree, it must first pass through the index. In order to make a new commit from the work-tree, each new file must pass through the index. Hence, the index/work-tree transitions are where cleaning and smudging take place.

To "clean" a file means to make it ready for committing. This cleaning process can, for instance, translate CRLF line endings into LF-only line endings. Or, using the ident filter, you can un-make many substitutions, or write your own filter to do virtually anything. To smudge a file means to make it ready for editing and/or use in the work-tree. This can, for instance, translate LF-only line endings into CRLF-endings. As with the cleaning process, you can use the ident filter or your own filter-driver to do anything you want. Git LFS uses these drivers to swap short references and entire file contents.

Hence, the exact answer is that line ending conversions are applied during those processes that copy files into or out of the index. The most common are these two:

• git add copies from work-tree into index.
• git checkout extracts to work-tree, from either commit into index and then to work-tree, or straight from index to work-tree.

It's only at these times that any of these CRLF-to-LF or LF-to-CRLF conversions occur. But Git has extra code that tries to intuit whether doing these conversions later will result in a change to existing committed data, even if it has not done them yet. That code will give you the warning messages you are seeing:

warning: LF will be replaced by CRLF ...
warning: CRLF will be replaced by LF ...

These warnings come out if you enable the "safe crlf" option. Because they come from different code run at different times, everything can be very confusing.

这篇关于什么是“签出代码”在git文档中是否表示行尾？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！