什么"检查代码"在git文档中表示行结尾?

时间:2017-10-11 18:45:36

标签: git gitattributes core.autocrlf

我真的很困惑"检查代码"表示在以下页面中:https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#__code_core_autocrlf_code

  

如果您使用的是Windows计算机,请将其设置为true - 这会在您签出代码时将LF结尾转换为CRLF:

添加文件时是否意味着什么?因为无论何时我将core.autocrlfinput更改为true,反之亦然,我在添加文件时会看到差异("检查"意味着&# ?34;添加&#34):

> 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

3 个答案:

答案 0 :(得分:4)

(注意:我正在尝试回答基本问题,这似乎真的是:如果结帐意味着git checkout,为什么我会在git add期间收到这些消息?

关于这方面的文档有点草率,可能是故意的,因为完全正确的细节有点模糊。要在概念层面上理解它,您应该将行结束修改视为更通用的涂抹 clean 过滤的一部分(因为这实际上是如何实现的) )。

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

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

文件可以在各个方向复制,但所有提交始终是只读的。因此,您可以从HEAD提交复制到索引,或从索引复制到工作树。您也可以从工作树复制到索引中。

(您也可以从索引中进行 new 提交。这样就会留下旧的HEAD提交,而新的提交会变成 HEAD提交。所以在创建之后新提交,HEAD提交和索引匹配。这不是因为我们修改了任何提交;我们不能这样做。这是因为我们添加了一个新的提交,由索引构成,然后我们停止调用旧的提交HEAD并将新的调用称为HEAD。)

请注意,索引位于HEAD和工作树之间。为了将任何文件从HEAD复制到工作树,它必须首先通过索引。为了从工作树进行新的提交,每个新文件必须通过索引。因此,索引/工作树转换是清理涂抹的地方。

“清理”文件意味着准备好提交。例如,该清洁过程可以将CRLF线路末端转换为仅LF线路末端。 Or, using the ident filter, you can un-make many substitutions,或编写自己的过滤器来做任何事情。 涂抹文件意味着准备好在工作树中进行编辑和/或使用。例如,这可以将仅LF的行结尾转换为CRLF结尾。与清洁过程一样,您可以使用ident过滤器或您自己的过滤器驱动程序来执行您想要的任何操作。 Git LFS使用这些驱动程序交换短引用和整个文件内容。

因此,确切的答案是在将文件复制到索引中或从索引中复制出来的进程中应用行结束转换。最常见的是这两个:

  • git add从工作树复制到索引。
  • git checkout提取到工作树,从提交到索引再到工作树,或直接从索引到工作树。

在这些时间这些CRLF到LF或LF到CRLF转换中的任何一个都会发生。但Git有额外的代码试图直观以后进行这些转换是否会导致对现有提交数据的更改,即使它尚未完成。 代码将为您提供您所看到的警告消息:

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

如果启用“safe crlf”选项,则会出现这些警告。因为它们来自不同时间运行的不同代码,所以一切都会非常混乱。

答案 1 :(得分:2)

请注意,在core.safecrlf设置为truewarn时看到的那些end of line conversion warnings一直不会在结帐时工作,因为它可能会被错误地触发对于的内容,使用CRLF作为行结尾。

这已在Git 2.16(2018年第一季度)中修复

commit 649f1f0(2017年12月8日)和commit 86ff70a(2017年11月26日)Torsten Bögershausen (tboegi)Junio C Hamano -- gitster --于2017年12月27日commit 720b176合并)

  

convert:加强安全autocrlf处理

     

当文本文件与CRLF一起提交并且文件被提交时   再次,如果.gitattributs有" text=auto"则保留CRLF。   这是通过分析存储在索引中的blob的内容来完成的:   如果' \r'如果发现,Git认为blob是与CRLF一起提交的。

     

简单搜索' \r'并不总是按预期工作:
  文件以UTF-16编码,带有CRLF并被提交。 Git将其视为二进制   现在内容转换为UTF-8。在下一次提交时,Git会对待   文件作为文本,CRLF应转换为LF,但不是。

     

has_cr_in_index()替换为has_crlf_in_index()。当没有' \ r'找到了,   直接返回0,这是最常见的情况   如果' \r'发现,内容得到更深入的分析。

答案 2 :(得分:0)

考虑一个图书馆。当您从图书馆查看图书时,在您重新检查之前,没有其他顾客可以访问该图书。

较旧的集中版本控制系统的工作方式类似;当你"签出"一个文件,系统锁定了该文件,没有其他用户可以签出相同的文件,直到您重新签入。

较新的版本控制系统倾向于允许多个用户同时处理文件,要求将不兼容的更改合并在一起,而不是严格序列化对文件的访问。术语"检查"但仍然用于指示将文件从存储库复制到工作目录的过程。