Subject: Re: Newbie grief

From: Rich Pixley <[email-masked]>
Date: Tue, 01 May 2012 11:59:03 -0700

On 4/30/12 16:35 , Jan Krüger wrote:
> Hi Rich,
>
> On 05/01/2012 12:30 AM, Rich Pixley wrote:
>> I'm trying to do what seems like a simple thing in darcs, monotone,
>> mecurial, gnu arch, etc, but seems nearly impossible in git.  There's a
>> central repository, a long ways away on the other side of the internet.
>> So I want a local repository cache.  I'm going to be working on a number
>> of different features and different machines all simultaneously so I
>> really don't want them all to be pulling from the central repository.
>>
>> In other systems, this is a simple star network.  Clone a repository,
>> use, push, pull, etc.  But with git, I can't push unless the cache
>> repository is bare, but if the cache repository is bare, then a change
>> to the central repository will cause the two to become wedged since
>> neither can push or fetch the other.
> If the 'cache repository' is set up using "git clone --mirror" and you
> push to the primary repository only, that makes the cache repo a
> definite slave, so you can always run "git fetch" on it without any
> trouble. You can even enforce this by denying all pushes to the cache
> repo, thus eliminating any chance of accidental misuse.
>
> Conveniently, git allows you to specify a different URL for fetch and
> push in your local working repositories.
Thank you.

For completeness, Michael Witten posted details for a comparable 
architecture where the data flow is in the other direction.  Leaf 
repositories push/pull to/from the cache, pull from the central 
repository in order to merge changes, then push to the cache to share 
locally.  Eventually, some leaf repository will push to the central.

Michael's approach has the advantage that the cache repository can be 
unattended and that my changes can be circulated locally before becoming 
visible to the wider, central repository audience.

Both approaches cleverly avoid potential collisions in the cache 
repository by working around them.  And, of course, some combinations of 
the two will work too.

--rich