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

Hi,

On Tue, 11 Dec 2007, Junio C Hamano wrote:

Kristian Høgsberg [off-list ref] writes:

quoted

On Tue, 2007-12-11 at 15:59 -0500, Daniel Barkalow wrote:

quoted

On Tue, 11 Dec 2007, Kristian Høgsberg wrote:

quoted

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.

I can understand that feeling, but I have to say that I am actually quite 
pleased with the progress in direction of having most of git as builtins.

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.

Yeah, I thought so too, but I'll also gladly take the builtin first.

There are a handful issues in that approach with the current git-remote, 
and that was why I also thought recent "git remote in C" by Dscho a bit 
unfortunate, as enhancements and interface fixes (both user and machine) 
tend to be much easier in scripted version.

And here I have to disagree strongly.  I _wasted_ a _week_ on trying to 
fix that stupid "add --mirror && prune" bug in the scripted version.  It 
was absolutely horrible.  And I felt like a moron after that week.

In contrast, it was easy as chocolate cake to fix it in the builtin 
remote.

Now, if you not only hinted in some mail that something is wrong with 
builtin-remote, but gave me some input, I could fix that in the builtin, 
too.

What the current "git clone" does that are not naturally expressed by
the above sequence are:

 * HEAD discovery

   The code can be lifted from the scripted version and transplanted to
   git-remote.  And to make "origin" and other remotes added by "git
   remote add", this logic needs to be moved to "git remote".

   However, before rewriting the "git remote" to C, it would be really
   nice if we can update the native protocol so that we can reliably
   find out which branch HEAD points at.  The current code guesses, only
   because the native protocol does not carry that information [*1*].
   Worse yet, even though the current code _knows_ this information when
   going over dumb protocols, it discards it to use the same guessing
   logic as used by the native protocol.

I wonder why this should be easier with git remote in Perl.  IMHO it is 
easier with git remote in C.

 * --shared optimization

   This is a very easy addition to "git remote add".  You make sure that
   the added remote repository is on a local machine, and set up
   alternates to point at its object store.

Concur.

Since I want to lose that dependency on cpio on Windows (which we fake by 
using tar), I'll implement this in C anyway.

Ciao,
Dscho