master TOC | chapter TOC | support
Mirroring a repo is simple in git; you just need code like this in a
post-receive hook in each repo:
#!/bin/bash
git push --mirror slave_user@mirror.host:/path/to/repo.git
# if running gitolite, the $GL_REPO variable could be useful:
# git push --mirror slave_user@mirror.host:/repo/base/path/$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:
faster reads for everyone: host a slave in every city you have a sizable number of developers in, and have them access their local server instead of hitting the WAN, at least for 'fetch' operations.
faster writes for most devs: one server doesn't have to be the master for all repos! You can choose where a repo gets "mastered" based on where the majority of that repo's users are.
This was the single biggest motivation for the re-work of gitolite's mirroring; the rest of the cool stuff just happened as this feature took shape.
transparent writes: if all the mirrors are in your control (i.e., you trust their authentication) pushes to a slave can be transparently redirected to the master, so developers simply access their local server for everything. They don't need to know where the master is, so they're insulated from any changes you make behind the scenes.
This is as close to active-active mirroring as you can get without worrying about race conditions and similar problems.
partial mirroring: all repos don't have to go all mirrors. You can choose not to mirror a repo at all, or mirror it only to certain servers. This could be due to any reason: repo too big/high-traffic for the server, repo has crypto code and the server is in a non-free country, repo has no local users at that site, or (in autonomous setups) the server admin simply doesn't want to mirror this specific repo.
late mirroring: if you're ok with the lag, you can have some mirrors updated only at certain times of the day, (with a simple command), instead of every time a push happens.
autonomous mirrors: finally, your mirrors don't have to be totally under your control. They can be owned by someone else, and you negotiate your mirroring with them.
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.
Servers can host 3 kinds of repos: master, slave, and local.
A repo can be a master on one and only one server. A repo on its "master" server is a native repo, on slaves it is "non-native".
A slave repo cannot be pushed to by a user. It will only accept pushes from a master server. (Exception: see the "redirecting pushes" section later)
A local repo is not involved in mirroring at all, in either direction.
conf/gitolite.conf file: LinkHere are some samples of what is possible.