Petr Baudis <pasky@xxxxxxx> wrote: > 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] > > (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). I think that's more `git fetch --all`. You are pulling every remote head available at a given remote into a subdirectory of your own ref space. That's rather different than replacing your entire ref space with the one available on the remote, which is what --mirror-all is doing and what you wanted for the hosting you are offering. > ..snip.. > > (the archive vs active repacking strategy we talked about, > > Hmm, I think I've missed this, I must look that in the archive. Junio pushed the core code out but nobody has done the Porecelain for it. The basic idea is to prevent repacking every pack all of the time; there's probably no reason to repack a 100 MiB pack file every time you repack your loose objects so you might want to keep say a <5 MiB "active pack" holding your recent created objects and repack that frequently and a larger 100+ MiB "history pack" holding everything else. Maybe you repack everything on a longer time scale, such as once a year. > > 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. Borrowing your line: Hmm, I think I've missed this, I must look that in the archive. :-) -- Shawn. - 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