Re: git reset for index restoration?

[Jeff King <peff@peff.net>]

[+cc Junio for cache-tree expertise]

On Thu, May 22, 2014 at 03:09:59PM -0400, Jeff King wrote:

> > > does show some improvement. Perhaps "git reset" is not writing out the
> > > cache-tree extension?
> [...]
> 
> Possibly. There is a call to prime_cache_tree in builtin/reset.c, which
> looks like it should trigger during a "mixed" or "hard" reset (and
> without arguments, you should have a mixed reset). But it doesn't seem
> to get called. I haven't traced it further.

So here's what's happening. The prime_cache_tree call is in reset_index,
and was added by:

  commit 6c52ec8a9ab48b50fc8bf9559467d5a4cf7eee3b
  Author: Thomas Rast <trast@student.ethz.ch>
  Date:   Tue Dec 6 18:43:39 2011 +0100
  
      reset: update cache-tree data when appropriate
      
      In the case of --mixed and --hard, we throw away the old index and
      rebuild everything from the tree argument (or HEAD).  So we have an
      opportunity here to fill in the cache-tree data, just as read-tree
      did.
      
      Signed-off-by: Thomas Rast <trast@student.ethz.ch>
      Signed-off-by: Junio C Hamano <gitster@pobox.com>

But that was counteracted by:

  commit 3fde386a40f38dbaa684c17603e71909b862d021
  Author: Martin von Zweigbergk <martinvonz@gmail.com>
  Date:   Mon Jan 14 21:47:51 2013 -0800
  
      reset [--mixed]: use diff-based reset whether or not pathspec was given
      
      Thanks to b65982b (Optimize "diff-index --cached" using cache-tree,
      2009-05-20), resetting with paths is much faster than resetting
      without paths. Some timings for the linux-2.6 repo to illustrate this
      (best of five, warm cache):
      
              reset       reset .
      real    0m0.219s    0m0.080s
      user    0m0.140s    0m0.040s
      sys     0m0.070s    0m0.030s
      
      These two commands should do the same thing, so instead of having the
      user type the trailing " ." to get the faster do_diff_cache()-based
      implementation, always use it when doing a mixed reset, with or
      without paths (so "git reset $rev" would also be faster).
      
      Timing "git reset" shows that it indeed becomes as fast as
      "git reset ." after this patch.
      
      Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
      Signed-off-by: Junio C Hamano <gitster@pobox.com>

We never call reset_index now, because we handle it via diff.  We could
call prime_cache_tree in this case, but I'm not sure if that is a good
idea, because it primes it from scratch (and so it opens up all those
trees that we are trying to avoid touching). I'm not sure if there's an
easy way to update it incrementally; I don't know the cache-tree code
very well.

-Peff