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

On Sun, Sep 5, 2010 at 3:09 PM, Elijah Newren [off-list ref] wrote:

n Sun, Sep 5, 2010 at 1:54 AM, Nguyen Thai Ngoc Duy [off-list ref] wrote:

quoted

On Sun, Sep 5, 2010 at 10:13 AM, Elijah Newren [off-list ref] wrote:

quoted

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

That's a really good idea.  I'll look into that.

Hmm..maybe before I get ahead of myself, I should back up for a
second.  Which way do we think is better -- handling this in
cache_tree_update() or doing a fixup in commit_tree()?  If the latter,
then I should just drop my 7/15 and 8/15 for your 13/17 and 14/17.  If
the former, then it makes sense to look into this change you suggest.
In that case, we'd probably keep my 7/15 but drop 8/15 for patch(es)
that implement your idea above.  But you're more familiar with the
index format than I am and it's your idea, so you'd probably be the
better one to implement it.

Thoughts?

Elijah