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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
