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.
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.
--
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