git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
To: Elijah Newren <newren@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: Mon, 6 Sep 2010 15:02:50 +1000	[thread overview]
Message-ID: <AANLkTikvJoVdUWAbQw0xT=JOiry4FaA0jsOMTNf=iZqH@mail.gmail.com> (raw)
In-Reply-To: <AANLkTinufi3TwnPZ+smq5FE5S3zZdQSzKpqYv=hVfcLV@mail.gmail.com>

On Mon, Sep 6, 2010 at 2:42 PM, Elijah Newren <newren@gmail.com> wrote:
> 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?

The former makes more sense. I still keep an eye on remote merge
support. Think of this case: you request a remote merge and have a
completely new base tree, different from HEAD. Then you get some
conflicts inside narrow/sparse area. By the time you resolve all
conflicts and are about to commit, where do you get the base tree?

It could follow the same way merge does, store it in a file in
$GIT_DIR, similar to $GIT_DIR/MERGE_HEAD, and make "git commit" pick
it up. Or just store it in index. You would need to (or should) change
the index anyway, to prevent naive git implementation from using it.
It makes more sense to put some more in index rather than a separate
file. Some commands (especially "git commit") make use of temporary
index. I think putting the base tree in index is a good point here,
but I'm not quite sure.

Anyway if you want to play with it, apply this on top of my 04/17
(then change index_state.narrow_base to something suitable for sparse
clone)

diff --git a/cache.h b/cache.h
index 9c014ef..c7d626d 100644
--- a/cache.h
+++ b/cache.h
@@ -293,6 +293,7 @@ struct index_state {
 	struct cache_tree *cache_tree;
 	struct cache_time timestamp;
 	char *narrow_prefix;
+	unsigned char narrow_base[20];
 	void *alloc;
 	unsigned name_hash_initialized : 1,
 		 initialized : 1;
diff --git a/read-cache.c b/read-cache.c
index 250013c..15c1c9e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1191,7 +1191,8 @@ static int read_index_extension(struct
index_state *istate,
 		istate->resolve_undo = resolve_undo_read(data, sz);
 		break;
 	case CACHE_EXT_NARROW:
-		istate->narrow_prefix = xstrdup(data);
+		hashcpy(istate->narrow_base, data);
+		istate->narrow_prefix = xstrdup(data+sizeof(istate->narrow_base));
 		break;
 	default:
 		if (*ext < 'A' || 'Z' < *ext)
@@ -1396,6 +1397,7 @@ int discard_index(struct index_state *istate)
 	istate->alloc = NULL;
 	istate->initialized = 0;
 	free(istate->narrow_prefix);
+	hashcpy(istate->narrow_base, (const unsigned char *)EMPTY_TREE_SHA1_BIN);
 	istate->narrow_prefix = NULL;

 	/* no need to throw away allocated active_cache */
@@ -1627,11 +1629,15 @@ int write_index(struct index_state *istate, int newfd)
 			return -1;
 	}
 	if (get_narrow_prefix()) {
+		struct strbuf sb = STRBUF_INIT;
 		char *buf = get_narrow_string();
-		int len = strlen(buf)+1;
-		err = write_index_ext_header(&c, newfd, CACHE_EXT_NARROW, len) < 0 ||
-			ce_write(&c, newfd, buf, len) < 0;
+		int len = 20+strlen(buf)+1;
+		strbuf_add(&sb, istate->narrow_base, 20);
+		strbuf_addstr(&sb, buf);
 		free(buf);
+		err = write_index_ext_header(&c, newfd, CACHE_EXT_NARROW, len) < 0 ||
+			ce_write(&c, newfd, sb.buf, len) < 0;
+		strbuf_release(&sb);
 		if (err)
 			return -1;
 	}
-- 
Duy

  reply	other threads:[~2010-09-06  5:02 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
2010-09-06  5:02         ` Nguyen Thai Ngoc Duy [this message]
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='AANLkTikvJoVdUWAbQw0xT=JOiry4FaA0jsOMTNf=iZqH@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=newren@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).