Re: git reset for index restoration?

From: Jeff King <peff@peff.net>
Date: May 22, 2014, 18:39 UTC
Message-ID: <20140522183930.GB1167@sigill.intra.peff.net>
In-Reply-To: <1400782642.18134.8.camel@stross>

On Thu, May 22, 2014 at 02:17:22PM -0400, David Turner wrote:

Show 7 quoted lines

> 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