On Thu, 2014-05-22 at 14:58 -0700, Junio C Hamano wrote: > David Turner <dturner@xxxxxxxxxxxxxxxx> writes: > > > 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. > > 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. -- 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