Junio C Hamano wrote: > For most callers of prime_cache_tree(), like the ones in "git > read-tree" and "git reset", it is immediately obvious that we just > read from the same tree, and we should have everything from the tree > and nothing else in the resulting index, so it is clear that the > prime_cache_tree() call is recreating the same cache-tree > information that we already should have computed ourselves, and > these calls can go (or if "prime" is still cheaper than "update", > these callers can pass an option to tell unpack_trees() to skip the > cache_tree_update() call, because they will call "prime" immediately > after). > After some basic performance testing of `git reset [--hard]`, it's not clear whether `cache_tree_update` is definitively faster or slower than `prime_cache_tree`; more conclusive results would indicate which of the two could be skipped. I'd like to defer this to a future patch (tracking it with an internal issue so I don't forget) where I can perform a more thorough analysis across all of the commands currently using `prime_cache_tree` and update its usage accordingly.
