On Thu, 2014-05-22 at 14:34 -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> 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. -- 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