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. > Furthermore, in directory entry format: > > The last 24 bytes (4-byte number of entries + 160-bit object name) are > for the cache tree. An entry can be in an invalidated state which is > represented by having -1 in the entry_count field. If an entry is in > invalidated state, the next entry will begin after the number of > subtrees, and the 160-bit object name is dropped. > > Dropping objname out of invalid (cache-)trees is a bad idea. When you > generate tree objects (aka cache_tree_update), you'll need objname > field again, which means structure change and directory entry rewrite. > If objname is always there, you can just overwrite objname with new > value. Though this may bring race condition issue back to directory > entries. The same approach on file entries might be reused. Yes you're right, at least the field for the object name (even if 0) should always be there. -- 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