On Fri, 2014-05-23 at 06:33 +0700, Duy Nguyen wrote: > On Fri, May 23, 2014 at 5:18 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > ... and the "incrementally repair" Peff talks about would be to > > cover more cases where we may know (either because we have already > > computed it to write out a subtree, or we have just read from a > > known tree to populate a part of the index and we know the paths in > > the index that correspond to that subtree are exactly the same ones > > as found in the tree we read from) parts of the cache-tree can be > > updated with tree object names for subtrees, but we don't do > > anything right now. > > I wanted to do this but it's hard. For "diff --cached" (which should > be where we find out and repair cache-tree), we flatten the trees in > traverse_trees() and let unpack-trees figure out the differences > against the index. The's no direct connection between a change and a > tree. Maybe I missed something. David if you are interested in "git > status" performance, this repairing thing could be important when the > worktree is large because the diff cost increases accordingly if > cache-tree is not fully populated. Empty cache-tree could cost us > nearly the same time we save with avoiding opendir/readdir.. I am interested, and I believe I might be able to start looking into it in a week or two. -- 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