Somewhere in the process of finishing up builtin-clone, the update of the working tree was lost. This was due to not using the option "merge" for unpack_trees(). Breakage noticed by Kevin Ballard. Test by Jeff King. Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx> --- > On Thu, May 15, 2008 at 12:44:02AM -0400, Jeff King wrote: > > > Hmm, builtin-clone does seem to be completely broken. It looks > > like unpack_trees is not doing its job for some reason, but I > > haven't looked further. But it surprised me that we aren't > > testing anything as simple as "clone works". The test below > > currently fails (though I am getting other test failures which > > are presumably related). I did not notice the breakage earlier, because I ran with a "twoway_merge" version of builtin-clone in my personal tree. builtin-clone.c | 3 +++ t/t5601-clone.sh | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/builtin-clone.c b/builtin-clone.c index a7c075d..8713128 100644 --- a/builtin-clone.c +++ b/builtin-clone.c @@ -525,7 +525,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix) memset(&opts, 0, sizeof opts); opts.update = 1; + opts.merge = 1; + opts.fn = oneway_merge; opts.verbose_update = !option_quiet; + opts.src_index = &the_index; opts.dst_index = &the_index; tree = parse_tree_indirect(remote_head->old_sha1); diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index dc9d63d..593d1a3 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -23,4 +23,11 @@ test_expect_success 'clone with excess parameters' ' ' +test_expect_success 'clone checks out files' ' + + git clone src dst && + test -f dst/file + +' + test_done -- 1.5.5.1.424.g3256b -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
