git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Kristian Høgsberg <krh@redhat.com>
Date
Dec 12, 2007, 18:25 UTC
Message-ID
<1197483943.10132.4.camel@hinata.boston.redhat.com>
In-Reply-To
<Pine.LNX.4.64.0712121237540.5349@iabervon.org>
On Wed, 2007-12-12 at 13:00 -0500, Daniel Barkalow wrote:
Show 24 quoted lines
> 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
Previous: Daniel BarkalowNext: Daniel Barkalow
Message 11 of 13 in “builtin-clone: Implement git clone as a builtin command.”
  1. builtin-clone: Implement git clone as a builtin command.Kristian Høgsberg, Dec 11, 2007
  2. Daniel BarkalowDec 11, 2007
  3. Kristian HøgsbergDec 11, 2007
  4. Junio C HamanoDec 12, 2007
  5. Junio C HamanoDec 12, 2007
  6. Johannes SchindelinDec 12, 2007
  7. Kristian HøgsbergDec 12, 2007
  8. Johannes SchindelinDec 12, 2007
  9. Kristian HøgsbergDec 12, 2007
  10. Daniel BarkalowDec 12, 2007
  11. Kristian HøgsbergDec 12, 2007
  12. Daniel BarkalowDec 12, 2007
  13. J. Bruce FieldsDec 24, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.