1

I want to setup a gitlab server on my local server and also use gitlab cloud as an offsite backup. Whenever a developer pushes their work i want it to go to both gitlab servers. I will do this using the following git commands

git remote set-url --add --push origin git://my_local_repo_url
git remote set-url --add --push origin git://my_gitlab_com_repo_url

I am concerned though that the two servers could go out of sync easily.

  1. What would happen if one of the servers was down during the push so one succeeded and one failed? How would i handle this?
  2. What if a developer forgot to add one of the remote URLs so only one of the servers was being pushed to and then the second remote URLs was added. What would happen the next push and how would i handle it?
  3. What other problems might I run into?
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
codetemplar
  • 671
  • 6
  • 19
  • I would suggest just having one remote and having the local push automatically to the cloud as a back-end thing. – Mort Apr 15 '17 at 14:47
  • Thanks. Do you mean having a post push hook on the local server to auto push to the cloud? – codetemplar Apr 15 '17 at 23:49
  • Yes. Except that it would probably be a post-receive hook. (You are pushing to the server that is receiving.) – Mort Apr 16 '17 at 01:42

1 Answers1

1

What would happen if one of the servers was down during the push so one succeeded and one failed? How would I handle this?

As mentioned in "pull/push from multiple remote locations", a failed push (because one of the remote repos, for any reason, was not available) can be fixed at the next push: the commits which were not pushed last time are pushed (in addition of the new ones) in the next push.

Even of the developer add the second remote later, as long as that second remote reflect what is in the first, that is OK: only new commits will be pushed (to both)

But the problem is:

  • divergent history (when one of the remote has commits that you do not have yet): you need to rebase on top of origin/master (in a fetch, origin always refer to the first url): then you can push
  • divergent remote (when both remote have different set of commits, because of two different history pushed to each one): you would need to push --force to one of those remote in order to rewrite/reset its history.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for your answer. With my second question regarding adding a second URL later on. What would happen if the second URL had no commits in its repo because only the first URL was being used? So the developer realised their mistake that they have only been committing and pushing to the one repo since the start of the project. They then add the second URL which is an empty repo because they haven't been using it and then pushed the latest commits to both repos? Would the first repo only receive the latest commits whilst the first received the entire history? Thanks again – codetemplar Apr 15 '17 at 13:49
  • @codetemplar then the developper can initialize that second repo with a git push --mirror /url/second/repo. After that, everything resume normally. – VonC Apr 15 '17 at 13:51
  • @codetemplar: the `git push` *command* deals in refspecs, so "what to push" is determined by the arguments: `git push ... `. Once the connection to the remote is running, though, *which commits to transfer for a refspec* is determined by *what the remote is missing.* If you are pushing `master`, you will transfer all commits reachable from your master, that they do not already have. Using `push --mirror` tells your Git to transfer everything from *every* reference you have, i.e., is equivalent to `git push refs/*:refs/*`. – torek Apr 15 '17 at 20:48
  • @torek Yes. I mentioned `push --mirror` to initialize one of the remotes which is empty. And I use the url of that remote directly instead of relying on the remote name. – VonC Apr 15 '17 at 20:50