On Thu, May 10, 2012 at 1:53 PM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: > > > On 05/08, Nguyen Thai Ngoc Duy wrote: >> Sorry I replied too fast. >> >> On Tue, May 8, 2012 at 9:25 PM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote: >> > On Tue, May 8, 2012 at 9:11 PM, Thomas Gummerer <t.gummerer@xxxxxxxxx> wrote: >> >>> * "160-bit object name for the object that would result from writing >> >>> this span of index as a tree." Is this always valid? >> >> >> >> No, this is only valid if the entry count is not -1. It's clarified >> >> now. >> > >> > ..and.. >> > >> >> The entry_count in the index is only valid, if the cache-tree is valid, >> >> which is not always the case. >> > >> > I think your trees are the cache-trees already. For invalid >> > cache-trees, you can just use all-zero sha-1 as the indicator. Then >> > entry_count can go away. > > How is it a cache-tree already? The subtree is covered, but the > entry_count is calculated recursively, while nfiles only keeps track of > the files directly in the directory, which is used for bisectability. Cache-tree maintains the information that what part of the index already has corresponding tree objects (and what sha-1). If a tree is changed, the tree all the way up must be invalidated (i.e. throw out the old sha-1 of trees). You have trees and objname for each tree. Invalidating a tree is simply erasing objname. Before performing a commit, we just need to traverse the trees from leaves up, generate tree objects for trees that do not have valid objname yet. -- Duy -- 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