From: Nguyen Thai Ngoc Duy Date: Thu, 10 May 2012 11:06:13 GMT Subject: Re: Index format v5 Message-ID: In-Reply-To: <20120510065303.GA98491@tgummerer> On Thu, May 10, 2012 at 1:53 PM, Thomas Gummerer 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 wrote: >> > On Tue, May 8, 2012 at 9:11 PM, Thomas Gummerer 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