From: "Kristian Høgsberg" <krh@redhat.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] builtin-clone: Implement git clone as a builtin command.
Date: Wed, 12 Dec 2007 13:25:43 -0500 [thread overview]
Message-ID: <1197483943.10132.4.camel@hinata.boston.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0712121237540.5349@iabervon.org>
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
next prev parent reply other threads:[~2007-12-12 18:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-11 19:57 [PATCH] builtin-clone: Implement git clone as a builtin command Kristian Høgsberg
2007-12-11 20:59 ` Daniel Barkalow
2007-12-11 23:38 ` Kristian Høgsberg
2007-12-12 3:12 ` Junio C Hamano
2007-12-12 3:20 ` Junio C Hamano
2007-12-12 11:12 ` Johannes Schindelin
2007-12-12 15:04 ` Kristian Høgsberg
2007-12-12 18:24 ` Johannes Schindelin
2007-12-12 15:24 ` Kristian Høgsberg
2007-12-12 18:00 ` Daniel Barkalow
2007-12-12 18:25 ` Kristian Høgsberg [this message]
2007-12-12 18:40 ` Daniel Barkalow
2007-12-24 1:52 ` J. Bruce Fields
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=1197483943.10132.4.camel@hinata.boston.redhat.com \
--to=krh@redhat.com \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).