Hi, On Tue, 11 Dec 2007, 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. 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
