On Thu, May 22, 2014 at 02:17:22PM -0400, David Turner wrote: > In fact, git status does not write the index (at least in this context). > And what is slow is not (only) checking over the working tree, but > reading the packs. There should be no need to read files from the ODB > at all, since the index knows those objects' SHA1s, and it can check > those against the working tree's SHA1s. Interestingly, if strace is to > be believed, git status doesn't even do check the working trees SHA1s > after a git reset; maybe reset already sets the stat bits? Keep in mind that "status" is running _two_ diffs. One between HEAD and the index, and one between the index and the working tree. Your timings might be more interesting just run "git diff-index --cached HEAD", which is the index->HEAD half of that, ignoring the working tree state entirely. Naively, running that diff will involve walking the trees and the index in parallel, which means opening a bunch of tree objects. The cache-tree index extension, however, records tree sha1s, which means we can avoid recursing into parts of the comparison. Comparing the two: $ rm .git/index $ git reset $ time git diff-index --cached HEAD real 0m0.044s user 0m0.040s sys 0m0.000s $ git reset --hard $ time git diff-index --cached HEAD real 0m0.012s user 0m0.008s sys 0m0.000s does show some improvement. Perhaps "git reset" is not writing out the cache-tree extension? -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