`git` 显示克隆后更改的文件，无需任何其他操作

git clone [email protected]:erocarrera/pydot (35a8d858b）在 Debian 中git config core.autocrlf input shows:

modified:   test/graphs/b545.dot
modified:   test/graphs/b993.dot
modified:   test/graphs/cairo.dot

这些文件具有 CRLF 行结尾，例如：

$ file test/graphs/cairo.dot
test/graphs/cairo.dot: UTF-8 Unicode text, with CRLF line terminators

The .gitattributes file contains:

*.py eol=lf
*.dot eol=lf
*.txt eol=lf
*.md eol=lf
*.yml eol=lf

*.png binary
*.ps binary

改变core.autocrlf对这些文件的状态没有影响。删除.gitattributes也没有效果。更改这些文件dos2unix不会改变他们的状态（如预期），并返回unix2dos与 没有什么区别diff与较旧的副本相比。文件权限看起来没有变化ls -lsa。另外，据我所知，这些文件具有统一的行结尾vi -b（因此不应该是这样的情况unix2dos or dos2unix从混合行结尾转换为统一行结尾，这可以解释这种奇怪的行为）。我在用着git版本 2.11.0。

什么是git认为有改变吗？

有点相关：

1. 即使内容相同，Git 状态也会显示文件已更改
2. git clone 之后直接显示为已修改的文件
3. 克隆一个 git 存储库，它已经有一个肮脏的工作目录...Whaaaaa？

在多次讨论的搜索过程中，我没有找到解释这种行为的答案。这个问题源于pydot # 163.

更详细地说：

git status

On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   test/graphs/b545.dot
    modified:   test/graphs/b993.dot
    modified:   test/graphs/cairo.dot

no changes added to commit (use "git add" and/or "git commit -a")

git diff test/graphs/b993.dot

warning: CRLF will be replaced by LF in test/graphs/b993.dot.
The file will have its original line endings in your working directory.
diff --git a/test/graphs/b993.dot b/test/graphs/b993.dot
index e87e112..8aa0872 100644
--- a/test/graphs/b993.dot
+++ b/test/graphs/b993.dot
@@ -1,10 +1,10 @@
-diGraph G{
-graph [charset="utf8"]
-1[label="Umlaut"];
-2[label="ü"];
-3[label="ä"];
-4[label="ö"];
-1->2;
-1->3;
-1->4;
-}
+diGraph G{
+graph [charset="utf8"]
+1[label="Umlaut"];
+2[label="ü"];
+3[label="ä"];
+4[label="ö"];
+1->2;
+1->3;
+1->4;
+}

UPDATE:

出于好奇，我提交了其中一个文件，转储git log -1 -p > diff, and vi -b diff表明git归一化

  1 commit 2021d6adc1bc8978fa08d729b3f4d565f9b89651
  2 Author:
  3 Date:
  4 
  5     DRAFT: experiment to see what changed
  6 
  7 diff --git a/test/graphs/b545.dot b/test/graphs/b545.dot
  8 index ebd3e8f..2c33f91 100644
  9 --- a/test/graphs/b545.dot
 10 +++ b/test/graphs/b545.dot
 11 @@ -1,9 +1,9 @@
 12 -digraph g {^M
 13 -^M
 14 -"N11" ^M
 15 -  [^M
 16 -  shape = record^M
 17 -  label = "<p0>WFSt|1571       as Ref: 1338    D"^M
 18 -]^M
 19 -N11ne -> N11:p0^M
 20 -}^M
 21 +digraph g {
 22 +
 23 +"N11" 
 24 +  [
 25 +  shape = record
 26 +  label = "<p0>WFSt|1571       as Ref: 1338    D"
 27 +]
 28 +N11ne -> N11:p0
 29 +}

其他奇怪的观察结果：git checkout克隆后任何这些文件都不会产生任何影响。After上面的提交，文件b545.dot工作目录中继续有 CLRF 行结尾。正在申请dos2unix其次是unix2dos没有做到git认为它已经改变了（而在提交之前它确实改变了，可能是因为坚定的文件有 CRLF 行结尾）。

这恰恰发生了because那些文件are致力于以 CRLF 结尾，但.gitattributes文件说以仅 LF 结尾提交它们。

Git 可以并且将会在两个地方进行 CRLF-vs-LF 转换：

• 从索引提取到工作树期间。存储在提交或索引中的文件始终假定处于“干净”状态，但是当从索引中提取该文件到工作树时，Git 应该应用由.gitattributes例如，以“仅将 LF 更改为 CRLF”的形式，也可以以 Git 调用的形式污迹过滤器.

• 将文件从工作树复制回索引期间。存储在工作树中的文件处于“弄脏”状态，因此此时，Git 应该应用任何“清理”转换：例如，将 CR-LF 更改为仅 LF，然后应用清洁过滤器.

请注意，这些转换有两个点can发生。这并不意味着他们will这两点都发生，只是这是两个可能的地方。作为.gitattributes文档说明，实际转换为：

• eol=lf：索引上没有 -> 工作树；工作树上的 CR-LF 到 LF-only -> 索引
• eol=crlf：索引 -> 工作树上仅 LF 到 CR-LF；工作树上没有 -> 索引

现在，实际位于存储库中、存储在提交中的文件是纯粹只读的。它可以never在该提交内进行更改。更准确地说，提交标识（通过哈希 ID）一棵树，该树标识（通过哈希 ID）具有任何内容的 Blob。这些哈希 ID 本身就是对象内容的加密校验和，因此它们自然都是只读的：如果我们尝试更改内容，我们得到的将是一个新的、不同的对象，具有新的、不同的哈希 ID。

Because git checkout实际上，通过将原始哈希 ID 从提交树复制到索引来工作，存储在索引中的文件版本必须与存储在提交中的文件版本相同。

因此，如果以某种方式——无论how— 提交的文件的形式与实际内容不一致.gitattributes指示 Git 执行的操作，无论事实如何，文件都会在工作树中变得“脏”you没有对他们做任何事！如果你要git add有问题的三个文件，这会将它们从工作树复制到索引，从而删除行尾的回车符。因此，他们在git status条款已修改但尚未提交。

去掉工作树版本中的回车符会使它们处于相同的状态：它们根据索引中的内容进行修改，因为git add现在将保持其仅 LF 行结尾不变，从而在索引中生成新的、不同的文件。

一个更有趣的问题是：他们是如何以错误的状态进入提交的？这不是我们可以回答的问题：只有那些做出这些承诺的人才能给出答案。我们只能推测。实现此目的的一种方法是添加并提交文件，而无需.gitattributes生效，然后设置.gitattributes生效，无需git add再次编辑文件。这样，CR-LF 结尾就会进入某人的索引，从而进入该用户的提交，即使.gitattributes file now说（但之前没有说过）任何new git add应该去掉回车符。