Jeff King <peff@xxxxxxxx> writes: > Interestingly, on my git.git repo, I had an empty cache. Running "git > read-tree HEAD" filled it (according to test-dump-cache-tree). It seems > that running "git checkout" empties the cache. So perhaps git could do > better about keeping the cache valid over time. At least in the early days unpack-trees built the result by manually adding an entry without calling the add_index_entry() all over the place, which meant that it was futile to pretend that there is even a slight chance that complex beast would correctly invalidate cached tree information at all the necessary places. I recall that I added a code to nuke the cache tree at the very beginning of "merging" codepaths to avoid any bogus cache tree result to be stored in the resulting index. These days, we have src_index and dst_index, and dst_index IIRC can start as empty in which case "start from kept information and selectively invalidate" would not work at all. When src_index and dst_index are the same, however, you should be able to keep the cached tree valid, at least in theory. -- 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