Re: [PATCH] Added --mirror-all to git-fetch.

[Shawn Pearce <spearce@spearce.org>]

Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Sep 20, 2006 at 06:06:11PM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> 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.