From: "Konstantin Khomoutov" <flatw...@users.sourceforge.net>
The other option is that you use two distinct 'master' branches named
"master-secure" and "master-dev" (and delete 'master'), such that they
are appropriately read only on the respective sides, and then let the
well disciplined devs (socially integrated...) do the merges to work
across the differences, to create a suitable reference branch.
On Wed, 28 Aug 2013 08:46:25 -0700 (PDT)
Anders Sveen <anders.r.sv...@gmail.com> wrote:
We have an set up with two network zones. One is the secure zone (no
internet access) and the other is the dev zone. Strangely development
will happen in both zones, not just the dev zone. :) I use Gitolite
to manage rights.
Between the zones I have one opening: Ssh from one machine in the
secure zone to one machine in the dev zone. So I want to establish
both these machines as Git repo's that clients in each zone pulls and
pushes from. And I was hoping changes would flow seamlessly between
the two hosts in seaprate zons. How can I sync between them?
I have looked into the "clone --mirror" option, but from what I can
gather a "remote update" will actually overwrite changes done to that
repo, so it would not work two way.
I have managed to get a setup where I pull from both via a clone with
added remotes, but this seems cumbersome and doesn't include all
branches by default.
I'm afraid the setup you intend to create cannot really be implemented
in an automated fashion simply becase you're facing a case of
multi-master replication with no way to automatically sort out arising
conflicts. I mean, if someone updates a branch named "master" on the
dev machine and someone else updates the same-named branch on the
secured machine, you're facing a fork, and since branches in Git are
light-weight (have only the single head and are in fact fully defined
by it solely) you can't just have this fork maintained at a central
"rendez-vouz" repo, and hence you ought to have a human (an
to deal with it.
So my proposition is to have "double mirroring": each of the boundary
machines should have full sets of bare repos -- one set of R/W repos
for its own network and another set of R/O repos are mirrors of the
repos from the secured network; on the other box, the sets are
Then provide no-brainer synchronization (either through gitolite's
built-in mirroring support or via cron tasks etc) between matching
of repos (say, each R/O repo mirror-fetches from its respective R/W
repo). This way, each network would see an R/O view of another
Each developer could fetch from the other network's repos but would
only ever push to its own network's R/W repos.
On the other hand, I fail to see what a setup that compilcated is
for. Is it possible to make a single machine available via SSH from
both networks and hence have a single set of centralized repos?
If you use separate feature branches which are then rebased and merged
to avoid conflicts, they conflicts between the two networks should be
That said, is the two sides won't talk you will get conflicts, so do
expect the tool to do everything ;-)
Do have a look at how git itself is developed with a layered approach to
the synchronization problem; 'master' is never rewound, 'next' is
occasionally rewound at choreographed points, 'pu' (potential updates)
is often rewound, so folks have a good handle on levels of stability and
where their patches have progressed to.
You received this message because you are subscribed to the Google Groups "Git for
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.