Re: Index format v5

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: May 10, 2012, 11:06 UTC
Message-ID: <CACsJy8Dx9jrC+8yC6eSsYbg2Yu6Xk+gkc-9Xe-iAy6+Uv_EoyA@mail.gmail.com>
In-Reply-To: <20120510065303.GA98491@tgummerer>

On Thu, May 10, 2012 at 1:53 PM, Thomas Gummerer <t.gummerer@gmail.com> wrote:

Show 25 quoted lines

>
>
> 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@gmail.com> wrote:
>> > On Tue, May 8, 2012 at 9:11 PM, Thomas Gummerer <t.gummerer@gmail.com> 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