Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter where Junio C Hamano <junkio@xxxxxxx> said that... ..snip.. > If there is reluctance against adding yet another new > command (and there certainly is), this feels more like a > cousin of "git-clone --bare". Certainly. But, what exactly are you proposing here? :-) (Besides possible change of the switch name.) Making this a git-clone option sounds even much worse. ..snip.. > (2) Although there is no inherent reason not allowing a working > tree associated with the repository that is kept updated > this way, the user will be utterly confused in a working > tree whose current branch head is updated like this, until > the working tree and the index is matched to the updated > HEAD. git-fetch --mirror-all can still be very useful even with a working copy if you are keeping all the remote heads in .git/refs/remotes/. I'd venture to say that in that case, this is frequently what you actually want when fetching from the repository (given that you have already let git clone do that once). ..snip.. > (the archive vs active repacking strategy we talked about, Hmm, I think I've missed this, I must look that in the archive. > combined with set of packs with staggered spans to help > commit walkers Pasky talked about quite a while ago). Yes, this is certainly one of things I would like to implement at repo.or.cz. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ Snow falling on Perl. White noise covering line noise. Hides all the bugs too. -- J. Putnam - 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