Re: [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 5, 2010 at 10:13 AM, Elijah Newren <newren@xxxxxxxxx> wrote:
> cache_tree_update() will write trees using the index.  With sparse clones,
> the index will only contain entries matching the sparse limits, meaning
> that the index does not provide enough information to write complete tree
> objects.  Having cache_tree_update() take a tree (typically HEAD), will
> allow new complete trees to be constructed by using entries from the
> specified tree outside the sparse limits together with the index.

You are moving it closer to the index (from my view because I changed
in commit_tree()). This makes me think, why don't you move the base
tree into the index itself?

The index is supposed to save the image of full worktree. While you
don't have all path names, you have the clue to all of them, the base
tree. To me, that means it belongs to the index. That would reduce
code change to
 - cache-tree.c (generate new tree from the base tree and index)
 - read-cache.c (new sparse-clone index extension)
 - index writing operations (save the base tree in index): read-tree and merge
-- 
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]