Re: git reset for index restoration?

[David Turner <dturner@twopensource.com>]

On Thu, 2014-05-22 at 14:58 -0700, Junio C Hamano wrote:
> David Turner <dturner@twopensource.com> writes:
> 
> > On Thu, 2014-05-22 at 14:34 -0700, Junio C Hamano wrote:
> >> Jeff King <peff@peff.net> writes:
> >> 
> >> > [+cc Junio for cache-tree expertise]
> >> > ...
> >> > 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.
> >> 
> >> The cache-tree is designed to start in a well-populated state,
> >> allowing you to efficiently smudge the part you touched by
> >> invalidating while keeping the parts you haven't touched intact.
> >
> > As far as I can tell, the cache-tree does not in fact ever get into a
> > well-populated state (that is, it does not exist at all) under ordinary
> > git operation except by git reset --hard.  Perhaps this was already
> > clear from the previous traffic on the thread, but I wanted to make sure
> > Junio was also aware of this.
> 
> Yes.  As I said, that should not usually be a problem for those who
> do the real work (read: commit), at which time write-tree will fully
> populate the cache-tree.

Git commit does not in fact populate the cache-tree.