git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).