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
--
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