为什么在git diff或git status之后，触摸文件的git diff-index HEAD结果会更改? [英] Why does git diff-index HEAD result change for touched files after git diff or git status?

问题描述

如果我touch在git repo中跟踪的文件，并运行git diff-index HEAD，它将显示带有M的输出，表明该文件已被修改.例如，

If I touch a file tracked in a git repo, and run git diff-index HEAD, it will print output with M indicating the file has been modified. For example,

$ touch foo
$ git diff-index HEAD
:100644 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0000000000000000000000000000000000000000 M  foo

我不确定这是否有意义，但这不是问题.问题是，如果我运行git diff HEAD或git status，为什么输出会改变(没有差异)?

I am unsure if this makes sense or not, but that is not the question. The question is, why does the output change (to no diff) if I run git diff HEAD or git status?

$ touch foo
$ git diff-index HEAD
:100644 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0000000000000000000000000000000000000000 M  foo
$ git diff                  # no output
$ git diff-index HEAD       # no output

我希望结果(无论结果如何)在不应该更改任何内容的命令中保持不变.

I would expect the result, whatever it is, to stay the same across commands that are not supposed to change anything.

推荐答案

首先让我们看一下输出的含义:

Let’s first take a look at what the output means:

:100644 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0000000000000000000000000000000000000000 M  foo

手册从左至右说:

1. 冒号
2. "src"的模式； 000000(如果已创建或未合并).
3. 一个空格.
4. "dst"的模式； 000000(如果删除或未合并).
5. 一个空格.
6. sha1代表"src"； 0 {40}(如果已创建或未合并).
7. 一个空格.
8. sha1代表"dst"； 0 {40}(如果已创建，未合并或查看工作树").
9. 一个空格.
10. 状态，后跟可选的分数"数字.
11. 使用-z选项时使用制表符或NUL.
12. "src"的路径
13. 使用-z选项时的制表符或NUL；仅存在于C或R.
14. "dst"的路径；仅存在于C或R.
15. 使用-z选项时，使用LF或NUL终止记录.

1. a colon.
2. mode for "src"; 000000 if creation or unmerged.
3. a space.
4. mode for "dst"; 000000 if deletion or unmerged.
5. a space.
6. sha1 for "src"; 0{40} if creation or unmerged.
7. a space.
8. sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
9. a space.
10. status, followed by optional "score" number.
11. a tab or a NUL when -z option is used.
12. path for "src"
13. a tab or a NUL when -z option is used; only exists for C or R.
14. path for "dst"; only exists for C or R.
15. an LF or a NUL when -z option is used, to terminate the record.

有趣是第八点:

sha1代表"dst"； 0 {40}(如果已创建，未合并或查看工作树").

sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".

因此，在您的情况下，您将获得40个零，因此意味着创建"，未合并"或查看工作树".由于您仅触摸了文件，并且已经对其进行了跟踪，因此可以消除前两个选项.剩下的就是看看工作树" .

So in your case, you get 40 zeros, so that either means "creation", "unmerged" or "look at work tree". Since you only touched the file, and it was already tracked, you can eliminate the first two options. That leaves us with "look at work tree".

如果您使用git diff这样做(它将尝试为所有更改生成实际的内容差异，并因此实际上查看文件内容)，那么Git显然会发现根本没有更改，因此随后的通话不再对此有任何说明.

And if you do that, using git diff (which will try to generate actual content diffs for all changes and as such actually look at the file contents), then Git apparently finds out that there was no change after all, so subsequent calls no longer say anything about it.

此观察结果使我相信，默认情况下git diff-index仅会快速浏览文件，而实际上没有比较任何内容.由于您已修改文件日期，因此Git认为它是可能已更改"，因此需要更详细的外观才能正确找到它.

This observation makes me believe that by default git diff-index will only take a quick look at the files, without actually comparing any content. Since you have modified the file date, Git considers it as "possibly changed" and requires a more detailed look to figure it out properly.

如果运行带有选项的git diff-index，该选项要求它更彻底地查看文件，那么它也将找不到任何更改，例如使用-p选项生成补丁时(这是git diff所做的事情).

If you run git diff-index with an option that requires it to take a more thorough look at the files, then it will also not find any changes, e.g. when using the -p option to generate a patch (which is kind of what git diff does).

因此，如果更改文件修改日期而未提出任何实际声明，则可能只是为了优化性能而假定可以更改文件 .而是留下一个稍后再看"标记.

So it’s likely just a performance optimization to assume a file could be changed if the file modification date was changed, without making actual claims about it; instead it just leaves a "look at this later" marker.

这篇关于为什么在git diff或git status之后，触摸文件的git diff-index HEAD结果会更改?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！