Thanks, very helpful. What I'm actually after is a tree-to-filesystem comparison, regardless of index. I've currently got a "diff" thrown in as a "work-around" before "diff-index", but now I understand it's not a workaround at all. If there's a better way to achieve what I'm after, I'd appreciate a tip. Otherwise I'll just change the comments explaining why there's a "diff" in my script. andy > > 5. git diff correctly reports no changes > 6. git diff-index now also reports nothing 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 compares the and the files on the filesystem. git-diff-index --cached compares the and the index. git-diff-tree [-r] [...] compares the trees named by the two arguments. git-diff-files [...] 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html