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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thursday 18 March 2010 20:07:12 Shawn O. Pearce wrote:
> Andreas Gruenbacher <agruen@xxxxxxx> 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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]