Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> It is like having a "git diff" result cache: no one would think of >> stuffing that in the pack index. > > Do you want to try to kid me? You'll have to try harder. Caching "git > diff" results... no, really! I thought Nico meant caching the rename similarity matrix when he said "git diff" cache. In a narrow context of "log --follow" it may make sense. It also might help "blame" without -C. But I do not see how we would gain anything if we had that cache tied to the pack index. > After all, the parents, referenced tree and blob objects to change as > often as the objects in the pack: never. But I notice that the aspects of objects you listed: the parents, referenced tree and blob objects. The frequency of them changing does not depend on where the actual object is, either packed or loose. These aspects of an object (more specifically, you are talking about a commit object) never change either way. So I am somewhat puzzled. It does change if a particular commit and its associated objects are relevant to the traversal as refs change (especially when they rewind). Just like an old "kept" pack can suddenly have tons of irrelevant objects after refs are pruned (e.g. a branch is dropped), cached reachability data, even though they may stay correct, would become irrelevant when nobody starts traversing from an object that is no longer reachable. -- 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