Geek Answers Handbook

Why does the git diff-index HEAD result change for affected files after the state of git diff or git?

If I touch tracked the file in the git repository and git diff-index HEAD starts, it will print the output with M , indicating that the file has been modified. For instance,

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

I'm not sure if this makes sense or not, but that is not a question. The question is, why does the output change (without any difference) 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 that the result, whatever it may be, will remain unchanged in teams that should not change anything.

+6
source share
1 answer

Let's first see what exit means:

 :100644 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 0000000000000000000000000000000000000000 M foo

The manual says the following: from left to right:

  • colon.
  • mode for "src"; 000000 in case of creation or inaction.
  • space.
  • mode for "dst"; 000000 upon deletion or inaction.
  • space.
  • sha1 for "src"; 0 {40} if created or not loaded.
  • space.
  • sha1 for "dst"; 0 {40} if you create, don’t download, or see the "work tree".
  • space.
  • followed by the additional number "rating".
  • tab or NUL when the -z option is used.
  • path for "src"
  • tab or NUL when the -z option is used; exists only for C or R.
  • path for "dst"; exists only for C or R.
  • LF or NUL when the -z option is used to complete recording.

The eighth point is interesting:

sha1 for "dst"; 0 {40}, if created, does not load, or "looks in the work tree".

Thus, in your case, you get 40 zeros, so that either means “create”, “without work”, or “look at the work tree”. Since you were only touching the file and it has already been tracked, you can eliminate the first two options. This leaves us with a “look at the work tree”.

And if you do this using git diff (which will try to generate the actual content for all the changes and, as such, actually look at the contents of the file), then Git seems to detect that there were no changes, so the subsequent ones challenges no longer say anything about it.

This observation leads me to believe that by default, git diff-index will only quickly browse files without actually comparing the content. Since you changed the file date, Git considers it to be “possibly changed” and requires more detailed analysis to figure it out correctly.

If you run git diff-index with a parameter that requires a more thorough look at the files, then it will also not find any changes, for example. when using the -p option to create a patch (which is something like git diff ).

Thus, its possible performance optimization for file adoption can be changed if the file modification date was changed without actual requirements for it; instead, it simply leaves a “look at it later” marker.

+5
source

More articles:


All Articles