On Wed, 2007-12-12 at 13:00 -0500, Daniel Barkalow wrote:
> On Wed, 12 Dec 2007, Kristian Hgsberg wrote:
>
> > 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
-
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
