Re: [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index
- From
Elijah Newren <newren@gmail.com>
- Date
- Sep 6, 2010, 04:42 UTC
- Message-ID
- <AANLkTinufi3TwnPZ+smq5FE5S3zZdQSzKpqYv=hVfcLV@mail.gmail.com>
- In-Reply-To
- <AANLkTikK9vGgtzrrAAyqptPVHM2wjOjK_cH6GB0rgewP@mail.gmail.com>
On Sun, Sep 5, 2010 at 3:09 PM, Elijah Newren <newren@gmail.com> wrote:
Show 22 quoted lines
> n Sun, Sep 5, 2010 at 1:54 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote: >> On Sun, Sep 5, 2010 at 10:13 AM, Elijah Newren <newren@gmail.com> 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 > > 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