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?

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

Reply via email to