4

I am trying to set up a Git repo on a remote server of mine, that I am sharing with someone else. Only thing is, this is located in my LAN, which I am not always a part of. I would like to be able to have 2 remotes using the same branch, all synchronized, almost like a symlink (but with configs).

To make things harder, if I try to use the external IP as a remote while in the LAN, it will fail, as that maps to my router's own internal IP. I would like to be able to do git push/pull lan to push while in LAN, and git push/pull wan when not, and ensure neither complain about anything relating to the two of them being separate.

I would like to also ensure they use the same data for syncing between them, as the destination server is the same in either case. I have some experience with Git, but not enough to be able to do this and be sure that it will work as planned.

I do not want to try to sync both of them at once by setting 2 remote URLs for the one branch, as it will just make pushing/pulling very slow because of timeouts.

Assume I have set up LAN already, is up to date, and has an initial commit already, and WAN is not yet set up.

Say the server's internal IP is myserver.lan, and the external one is mydomain.org, how would I go about this?

Scott Weldon
  • 9,673
  • 6
  • 48
  • 67
Andrew
  • 65
  • 9

1 Answers1

2

As I commented below, one can add to a local repo as many remotes as you need:

git remote add upstream1 /url/first/repo
git remote add upstream2 /url/first/repo

Then a git push can select the right remote to use:

git push upstream1
# or
git push upstream2

The easiest would be add a script which would:

  • test for the right url (with, for instance, git ls-remote /url/to/remote/repo)

  • replace origin with the url that works in the current environment

    git remote set-url origin /url/that/works

That way, you always have just one remote to manage: the default one called 'origin'.
But each time you are switching environment, your script can update origin url.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I would prefer to have 2 seperate origins, that way, later on, I can just use a single line to explicitly choose, and not have to worry about delays with figuring out which mirror is correct. I am happy to do any number of commands/manual config changes to do this, but I would like to manually decide which remote to use in the end. EDIT: Added more info – Andrew Jul 13 '14 at 06:11
  • @Andrew but the script would make that "delay" only once per session, in order to update your origin. Then all your push/pull/fetch would run without delay. – VonC Jul 13 '14 at 06:40
  • I explicitly wanted to be able to specify multiple origins. That way, if I was to automate things more, I could make script writing easier for cron-based stuff, or whatever I choose to do, and make changing actual mirrors easier, without modifying scripts. – Andrew Jul 13 '14 at 06:45
  • @Andrew you can add as many remote as you want: `git remote add`, and you can at any time change the remote used by a branch: `git config branch..remote aRemoteName`. – VonC Jul 13 '14 at 06:46
  • I wanted to configure 2 remotes though. I know that I can configure 2 seperate remotes, which will show as seperate remote branches, and I can add 2 urls for a remote via either a command or configs, but I want to do the first and have them both use the same tree or whatever. By the way, this may be me misunderstanding how git works in this, so please do tell me if that is actually how it works. I am assuming that each remote stores the tree seperately, and requires you to checkout the remote to be able to switch, even if they technically are the same branch on the server. – Andrew Jul 13 '14 at 06:50
  • @Andrew Configuring two remotes (with git remote command) won't show them as separate branches: a remote is just an url alias. Each remote does not store the tree separately. – VonC Jul 13 '14 at 06:51
  • That is what I was unclear on. Thanks. I'll add the answer to the question to help explain it to others who also come along confused. – Andrew Jul 13 '14 at 06:53
  • @Andrew my answer is in the context of one unique upstream repo accessed through 2 different urls. Not 2 upstreams repos. – VonC Jul 13 '14 at 06:53
  • Then I guess I don't understand upstream properly... I wanted the 2 urls to almost act as aliases, but with different URLs. If that makes any sense... Also, I can't answer my own question for another 8 hours because of reputation being too low. – Andrew Jul 13 '14 at 07:03
  • @Andrew so you do have one unique upstream repo, then? Except you can access it through 2 different url depending on your environment, right? – VonC Jul 13 '14 at 07:05
  • I believe so. How does having 2 seperate upstream remotes pointing to the same server and same repo cause an issue when pushing/pulling then? – Andrew Jul 13 '14 at 07:06
  • @Andrew probably because a push/pull needs only one url to operate on (hence the script idea) – VonC Jul 13 '14 at 07:07
  • I specifically wanted to have the 2 URLs seperate, so I could manually choose which one. I want to do it like this so I can apply it to other situations where conditions can be vastly different, but still have a similar task. Like if you were to make a secondary testing git server before pushing to the main one (horrible example, but works in somewhat of a similar way in how I am trying to operate) – Andrew Jul 13 '14 at 07:10