Re: [PATCH] builtin-clone: Implement git clone as a builtin command.

On Wed, 2007-12-12 at 13:00 -0500, Daniel Barkalow wrote:

On Wed, 12 Dec 2007, Kristian Hgsberg wrote:

quoted

However, let me just say that the patch I sent is almost just that.
Part of the patch refactors init-db to be useful from clone, part of the
code is option parsing and figuring out the git dir, work tree.  Also,
the part of the patch that does 'git checkout' is approximately 20 lines
that end up calling unpack_tre() and then write_cache().  The bulk of
the work here is really just builtin boilerplate code, option parsing
and the builtin-clone tasks you describe below (HEAD discovery, --shared
and --reference optimizations and the local hardlink optimization - all
these are in the 500 line builtin-clone.c I sent).

And maybe it makes sense to use builtin-remote for the remote add -f
part, but the fetch part of the patch is 10 lines to set up for
fetch_pack().  So while I do agree that it makes sense to keep remotes
handling in one place, doing the fetch_pack() in builtin-clone.c doesn't
seem like a big duplication of code.  And either way, I agree with
Dscho, once we have either builtin-clone or builtin-fetch it's easier to
share code and refactor, and there is not a strong reason to do one or
the other first.

Er, we have builtin-fetch. We just don't have a way of calling it with all 
of the option parsing done, but that should be easy. I was expecting that 
step to get done when clone got converted, or maybe remote...

Ugh, I meant builtin-remote there, sorry.  I use fetch_pack() like the shell
script does, and it seem a lot easier that trying to call fetch:

        struct fetch_pack_args args;

        args.uploadpack = option_upload_pack;
        args.quiet = option_quiet;
        args.fetch_all = 1;
        args.lock_pack = 0;
        args.keep_pack = 1;
        args.depth = option_depth;
        args.no_progress = 1;

        refs = fetch_pack(&args, argv[0], 0, NULL, NULL);

Kristian