git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index
Date: Sun, 5 Sep 2010 22:42:53 -0600	[thread overview]
Message-ID: <AANLkTinufi3TwnPZ+smq5FE5S3zZdQSzKpqYv=hVfcLV@mail.gmail.com> (raw)
In-Reply-To: <AANLkTikK9vGgtzrrAAyqptPVHM2wjOjK_cH6GB0rgewP@mail.gmail.com>

On Sun, Sep 5, 2010 at 3:09 PM, Elijah Newren <newren@gmail.com> wrote:
> 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

  reply	other threads:[~2010-09-06  4:43 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-05  0:13 [RFC PATCH 00/15] Sparse clones Elijah Newren
2010-09-05  0:13 ` [RFC PATCH 01/15] README-sparse-clone: Add a basic writeup of my ideas for sparse clones Elijah Newren
2010-09-05  3:01   ` Nguyen Thai Ngoc Duy
2010-09-05  3:13     ` Elijah Newren
2010-09-06  3:14       ` Nguyen Thai Ngoc Duy
2010-09-05  0:13 ` [RFC PATCH 02/15] Add tests for client handling in a sparse repository Elijah Newren
2010-09-05  0:13 ` [RFC PATCH 03/15] Read sparse limiting args from $GIT_DIR/sparse-limit Elijah Newren
2010-09-05  0:13 ` [RFC PATCH 04/15] When unpacking in a sparse repository, avoid traversing missing trees/blobs Elijah Newren
2010-09-05  0:13 ` [RFC PATCH 05/15] read_tree_recursive: Avoid missing blobs and trees in a sparse repository Elijah Newren
2010-09-05  2:00   ` Nguyen Thai Ngoc Duy
2010-09-05  3:16     ` Elijah Newren
2010-09-05  4:31       ` Elijah Newren
2010-09-05  0:13 ` [RFC PATCH 06/15] Automatically reuse sparse limiting arguments in revision walking Elijah Newren
2010-09-05  1:58   ` Nguyen Thai Ngoc Duy
2010-09-05  4:50     ` Elijah Newren
2010-09-05  7:12       ` Nguyen Thai Ngoc Duy
2010-09-05  0:13 ` [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index Elijah Newren
2010-09-05  7:54   ` Nguyen Thai Ngoc Duy
2010-09-05 21:09     ` Elijah Newren
2010-09-06  4:42       ` Elijah Newren [this message]
2010-09-06  5:02         ` Nguyen Thai Ngoc Duy
2010-09-06  4:47   ` [PATCH 0/4] en/object-list-with-pathspec update Nguyễn Thái Ngọc Duy
2010-09-06  4:47   ` [PATCH 1/4] Add testcases showing how pathspecs are ignored with rev-list --objects Nguyễn Thái Ngọc Duy
2010-09-06  4:47   ` [PATCH 2/4] tree-walk: copy tree_entry_interesting() as is from tree-diff.c Nguyễn Thái Ngọc Duy
2010-09-06 15:22     ` Elijah Newren
2010-09-06 22:09       ` Nguyen Thai Ngoc Duy
2010-09-06  4:47   ` [PATCH 3/4] tree-walk: actually move tree_entry_interesting() to tree-walk.c Nguyễn Thái Ngọc Duy
2010-09-06 15:31     ` Elijah Newren
2010-09-06 22:20       ` Nguyen Thai Ngoc Duy
2010-09-06 23:53         ` Junio C Hamano
2010-09-06  4:47   ` [PATCH 4/4] Make rev-list --objects work together with pathspecs Nguyễn Thái Ngọc Duy
2010-09-07  1:28   ` [RFC PATCH 07/15] cache_tree_update(): Capability to handle tree entries missing from index Nguyen Thai Ngoc Duy
2010-09-07  3:06     ` Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 08/15] cache_tree_update(): Require relevant tree to be passed Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 09/15] Add tests for communication dealing with sparse repositories Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 10/15] sparse-repo: Provide a function to record sparse limiting arguments Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 11/15] builtin-clone: Accept paths for sparse clone Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 12/15] Pass extra (rev-list) args on, at least in some cases Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 13/15] upload-pack: Handle extra rev-list arguments being passed Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 14/15] EVIL COMMIT: Include all commits Elijah Newren
2010-09-05  0:14 ` [RFC PATCH 15/15] clone: Ensure sparse limiting arguments are used in subsequent operations Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='AANLkTinufi3TwnPZ+smq5FE5S3zZdQSzKpqYv=hVfcLV@mail.gmail.com' \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).