master TOC | chapter TOC | support | license

WARNING: This is not the latest gitolite; please see the README

mirroring gitolite servers

Mirroring a repo is simple in git; you just need code like this in a post-receive hook in each repo:

git push --mirror
# if running gitolite, the $GL_REPO variable could be useful:
# git push --mirror$GL_REPO.git

For a lot of people, though, mirroring is more than just 'backup', and their needs are complex enough that setup is hard.


Gitolite's mirroring used to be very rigid -- one master, any number of slaves, but the slaves are identical copies of the master. No variations allowed.

It's now been reworked to be much more flexible, to cater to almost any kind of setup you need. Here're some advantages:

As you can see, this is a bit more than a backup solution ;-)


RULE OF GIT MIRRORING: users should push directly to only one server! All the other machines (the slaves) should be updated by the master server.

If a user pushes directly to one of the slaves, those changes will get wiped out on the next mirror push from the real master server.

Corollary: if the primary went down and you effected a changeover, you must make sure that the primary does not come up in a push-enabled mode when it recovers.

Getting around rule number one: see the section on "redirecting pushes" later.

concepts and terminology

Servers can host 3 kinds of repos: master, slave, and local.

setting up mirroring

IMPORTANT cautions: Link

setup and usage: Link

commands to (re-)sync mirrors: Link


the conf/gitolite.conf file: Link

redirecting pushes: Link

example setups

Here are some samples of what is possible.

non-autonomous: Link

non-autonomous with local repos: Link

semi-autonomous: Link

autonomous: Link

discussion: Link


appendix A: example cronjob based mirroring: Link

appendix B: efficiency versus paranoia: Link