Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > I'm aware that Jeff's tackling at lower level, which retains > cache-tree for many more cases. > > But this patch seems simple and safe > to me, and in my experience this case happens quite often (or maybe I > tend to keep my index clean). Junio, any chance this patch may get in? I do not think we are talking about a duplicated effort here. By definition, the change to hook into unpack_trees() and making sure we invalidate all the necessary subtrees in the cache cannot give you a cache tree that is more populated than what you started with. And the train of thought in Peff's message is to improve this invalidation---we currently invalidate everything ;-) Somebody has to populate the cache tree fully when we _know_ the index matches a certain tree, and adding a call to prime_cache_tree() in strategic places is a way to do so. The most obvious is write-tree, but there are a few other existing codepaths that do so. Because prime_cache_tree() by itself is a fairly expensive operation that reads all the trees recursively, its benefits need to be evaluated. It should to happen only in an operation that is already heavy-weight, is likely to have read all the trees and have many of them in-core cache, and also relatively rarely happens compared to "git add" so that the cost can be amortised over time, such as "reset --(hard|mixed)". Switching branches is likely to fall into that category, but that is just my gut feeling. I would feel better at night if somebody did a benchmark ;-) One thing we do not currently do anywhere that _might_ be of merit is to make a call to cache_tree_update() instead of prime_cache_tree() when we already know that only a very small subpart of the cache-tree is invalid and it is cheaper to repair it by rehashing only a small portion of the index than to re-prime the entire cache tree with prime_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