Re: BUG in git diff-index

[Jeff King <peff@peff.net>]

On Thu, Mar 31, 2016 at 12:39:23PM +0000, Andy Lowry wrote:

> Following transcript illustrates what I believe to be a bug in git diff-
> index. The session used a git built from latest source, located in 
> /tmp/git/git.
> 
> 1. New repo, create empty file A, commit changes.
> 2. touch A
> 3. git diff-index reports A has changed, and reports bogus destination 
> SHA
> 4. This is stable behavior until next step
> 5. git diff correctly reports no changes
> 6. git diff-index now also reports nothing
> 
> My understanding is that git diff-index should care only about content 
> and file mode, not modification time.

This is working as designed (though I agree it is a little confusing).
From "git help diff-index":

       These commands all compare two sets of things; what is compared differs:

       git-diff-index <tree-ish>
           compares the <tree-ish> and the files on the filesystem.

       git-diff-index --cached <tree-ish>
           compares the <tree-ish> and the index.

       git-diff-tree [-r] <tree-ish-1> <tree-ish-2> [<pattern>...]
           compares the trees named by the two arguments.

       git-diff-files [<pattern>...]
           compares the index and the files on the filesystem.

Your invocation triggers the first, though it is not a true comparison
of what is on the filesystem, but rather a tree/index comparison, taking
into account the filesystem values. The all-zeroes sha1 indicates that
the index entry is not up to date with what is in the filesystem, but we
don't actually read the file contents to refresh the entry.

Back when diff-index was written, it was generally assumed that scripts
would refresh the index as their first operation, and then proceed to do
one or more operations like diff-index, which would rely on the refresh
from the first step.

Running the porcelain "git diff" does refresh the index, which is why
your step 6 shows no diff.

If you want a pure tree-to-index comparison, use --cached (this will
also be slightly faster, as it does not have to stat the working tree at
all).

-Peff