Subject: Re: [PATCH 0/9] Multiple remotes without conflicts

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 18 Mar 2010 20:42:49 +0100

On Thursday 18 March 2010 20:07:12 Shawn O. Pearce wrote:
> Andreas Gruenbacher <[email-masked]> wrote:
> > I'm still trying to find a simple and painless way of sharing the object
> > store among multiple repositories: the idea is to have a "parent"
> > repository which contains the actual object store, and a number of
> > "child" repositories which link to that object store.  The obvious
> > problem is garbage collection: we can only garbage collect the parent
> > once it has all refs of all its children.
> >
> > One way of ensuring that is to make each child a "remote" of the parent,
> > and to fetch all remotes first.  This works for branches, but not for
> > tags or for the reflog.
> 
> This just feels like the wrong solution.
> 
> Why can't we have a "$GIT_DIR/children" subdirectory with a symlink
> or file-containing-path to each child repository.  Modify the fsck
> and gc paths to include these additional reference and reflog spaces,
> and that's that.
> 
> Child registration is then just a matter of installing the symlink
> in the parent, or removing it, and gc/fsck never needs to worry
> about a fetch up front in order for it to be accurate.

Another way would be to add some kind of "child" flag to remotes, and to teach 
gc to fetch such children before doing its work (or check that they are up-to-
date).  I think it's much nicer to construct the "parent" repository in such a 
way that it includes all relevant refs locally: it will just look and behave 
like a "normal" repository.

Thanks,
Andreas