This version is still a mess, but it passes all of the tests. I'm
somewhat unconvinced by the test coverage for clone, however; the
last failure I found was actually for which heads get created in a
bare repository, and it was only failing when there was an extra one
in a non-bare clone in a test for something entirely different.

Thanks to Johannes Schindelin for various comments and improvements.
---
 Makefile                                      |    2 +-
 builtin-clone.c                               |  542 +++++++++++++++++++++++++
 builtin.h                                     |    1 +
 git-clone.sh => contrib/examples/git-clone.sh |    0 
 git.c                                         |    1 +
 t/t5701-clone-local.sh                        |    6 +-
 6 files changed, 548 insertions(+), 4 deletions(-)
 create mode 100644 builtin-clone.c
 rename git-clone.sh => contrib/examples/git-clone.sh (100%)

diff --git a/Makefile b/Makefile
index 7917509..aec2ac3 100644
--- a/Makefile
+++ b/Makefile
@@ -231,7 +231,6 @@ BASIC_LDFLAGS =
 
 SCRIPT_SH = \
 	git-bisect.sh \
-	git-clone.sh \
 	git-merge-one-file.sh git-mergetool.sh git-parse-remote.sh \
 	git-pull.sh git-rebase.sh git-rebase--interactive.sh \
 	git-repack.sh git-request-pull.sh \
@@ -348,6 +347,7 @@ BUILTIN_OBJS = \
 	builtin-checkout-index.o \
 	builtin-check-ref-format.o \
 	builtin-clean.o \
+	builtin-clone.o \
 	builtin-commit.o \
 	builtin-commit-tree.o \
 	builtin-count-objects.o \
diff --git a/builtin-clone.c b/builtin-clone.c
new file mode 100644
index 0000000..1b83062
--- /dev/null
+++ b/builtin-clone.c
@@ -0,0 +1,542 @@
+/*
+ * Builtin "git clone"
+ *
+ * Copyright (c) 2007 Kristian H
[ message continues ]

In git.git's "next" branch, unpack_trees() must specify source and target 
index.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---

	To be squashed into 10/11

 builtin-clone.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/builtin-clone.c b/builtin-clone.c
index e4047ed..3890e12 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -534,6 +534,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
 		opts.verbose_update = !option_quiet;
 		opts.merge = 1;
 		opts.fn = twoway_merge;
+		opts.src_index = &the_index;
+		opts.dst_index = &the_index;
 
 		tree = parse_tree_indirect(remote_head->old_sha1);
 		parse_tree(tree);
-- 
1.5.4.3.653.gbc310

--

[ message continues ]

Actually, I think the sensible thing is to just not do a merge here, since 
we know there's no index beforehand and the two trees are the same.

I think the odd twoway merge of two copies of HEAD is just an artifact of 
clone originally just doing "git checkout HEAD", and that got translated 
various times failing to notice the special cases.

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]

Hi,


Okay, but would oneway_merge not want to write the index, too (rightfully 
so)?

Ciao,
Dscho

--

[ message continues ]

I'm thinking:

  memset(&opts, 0, sizeof opts);
  opts.update = 1;
  opts.verbose_update = !option_quiet;
  opts.dst_index = &the_index;

  init_tree_desc(&t[0], tree->buffer, tree->size);
  unpack_trees(1, t, &opts);

That is, write it, but not read it, and only have one tree.

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]

Hi,


Yes.  And this sets dst_index (what I tried to hint at with my patch).

Ciao,
Dscho

--

[ message continues ]

Oh, yes. Your patch is what prompted me to fix that part (and to find that 
Linus's unpack_trees was in next now). But seeing src_index in your patch 
made me wonder what it wanted a source index for anyway, since this is the 
first index we've had in this repo.

	-Daniel
*This .sig left intentionally blank*
--

[ message continues ]

Hi,


Well, stupid copy-'n-paste.  Well, not all that stupid: because of the 
twoway_merge (and because the segmentation fault was in a line accessing 
src_index), I assumed that the src_index is needed.

But your explanation that oneway_merge is all we want makes tons of sense.

Ciao,
Dscho

--

[ message continues ]