2

I have 2 bare repositories. They are made like this:

ssh git@primary.com
git init --bare repo1
ssh git@backup.com
git clone --bare git@primary.com:repo1

One is used for development (let's call it primary) and one is used for backup (in case first is not accessible). Is it possible to automatically synchronize them - something like doing git pull on backup.

I guess you can't merge or pull on bare repository. Is there another way to have backup repository up to date, rather than this:

ssh git@backup.com
rm repo1 -fr
git clone -- bare git@primary.com:repo1

of course when primary wasn't accessible for a while and I used backup then I would want to update primary.

Also adding 2 remotes to the working repository is a solution, but you have to constantly push to the both of them, which can't happen if one is inaccessible.

All conflicts are resolved in the non-bare repositories

edit why do I need backup repository:

we use remote repository to exchange code and it's needed daily. usually people don't need code written by other developers, but that's not always the case. we lost contact with primary for 3 days and it was not easy to develop. I made second repository on another server and I cloned local, but I had to do that for a lot of projects and it's time consuming. I prefer to have the second repository automatically updated.

NickSoft
  • 3,215
  • 5
  • 27
  • 48
  • 1
    Just a short suggestion (not a complete solution): You may use a post-commit hook on "primary" to push changes to "backup", instead of pulling it from there. However, I dont see a reason for a "backup" repository, because thats is originally the reason to use a distributed vcs: Every clone is a backup. – KingCrunch Apr 05 '11 at 13:58

2 Answers2

3

You can use git push --mirror other-remote to mirror all the refs in one repository to another. This won't mirror the repository config or stashes, though - you might want to also look at this question's answers:

Update: In response to your clarified question and comment below, I should say that it's not safe to git push --mirror in both directions, since git push --mirror does a forced update of refs and removes deleted refs. For example, suppose your master on primary is ahead of that on backup and there's a new branch on primary that hasn't been mirrored yet - then a git push --mirror will reset the master branch on primary to an old state and delete the newly created branch.

In addition, even if you're only mirroring from primary to backup, it's not safe to allow people to push to backup, since anything new pushed solely to there would be removed by the next mirror.

So, what can you do? I'm assuming that when the primary repository is unavailable, that whole machine is unavailable. So, on the backup server, I would create one bare repository, as you suggest, that a cron job on primary will mirror the repository to. You shouldn't allow people to push to that mirrored repository, however - when the primary server goes down, clone the mirror to create a bare repository that people can push to in the mean time. When the primary server is back up, stop people from being able to push to that new repository on the backup, then merge the changes from there locally and push the new work back to the primary server.

Community
  • 1
  • 1
Mark Longair
  • 446,582
  • 72
  • 411
  • 327
  • I tried it. Since backup had some new commits I had `! [remote rejected] origin/HEAD (inconsistent aliased update)` message. I tried `git push --mirror primary` from backup and it succeeded. After that everything was working fine. My question is is it completely safe to `git push --mirror` from both sides when it's possible that some are not up date. – NickSoft Apr 06 '11 at 08:15
  • That's pretty bad. I wanted semi-automatic sync, but I guess it's not possible if you push on both repos in the same branch different stuff. I will wait a bit for other answers before I accept an answer and I'll make some tests. – NickSoft Apr 07 '11 at 08:44
0

Use a crontab script or similar to run git push --mirror remote to your backup on a regular basis. You could also add a commit hook to automatically force push to another remote on updates, this way you don't have a "failure window". No need to update from backup since it will presumably never have any new or updated content of it's own.

omnisis
  • 1,208
  • 8
  • 9