On Tue, 2007-12-11 at 19:12 -0800, Junio C Hamano wrote: > Kristian Høgsberg <krh@xxxxxxxxxx> writes: > > > On Tue, 2007-12-11 at 15:59 -0500, Daniel Barkalow wrote: > >> On Tue, 11 Dec 2007, Kristian Høgsberg wrote: > >> > >> > Ok, don't flame me, I know this isn't appropriate at the moment with > >> > stabilization for 1.5.4 going on, but I just wanted to post a heads up > >> > on this work to avoid duplicate effort. It's one big patch at this point > >> > and I haven't even run the test suite yet, but that will change. > >> > >> Is that why you misspelled Junio's email address? :) > > > > Hehe, yeah, do not mess with maintainers in release mode :) > > Actually this is a bit unfortunate, regardless of everybody being in > release and bugfix only mode. Well, let's just pick up the discussion in January, I have a lot of other stuff I'm trying to do anyway :) > I was hoping that the evolution path for clone would be to first make it > a very thin wrapper around: > > git init > git remote add -f > git checkout > > sequence. 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. cheers, 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
