Synchronizing Git repos across machines without push

Question

I've got three computers which should have the same settings for all their applications. Since all of them have processes running using those settings, I never want to push, instead I'd like for each of them to track the other two, and pull only when I'm logged in.

After working a couple of days on this, all the articles I've found seem to assume that you'd want to push to a central repository before pulling from that at the other machines, but that seems like a waste of space and (transfer) time. Are there any guides which can explain clearly how to do something like this?

Edit 2: Pat Notz gave the necessary tip to correct .git/config:

[branch "master"]
  remote = machine2
  merge = refs/heads/master
[remote "machine1"]
  url = ssh://192.168.0.4/~/settings
  fetch = +refs/heads/*:refs/remotes/machine1/*
[remote "machine2"]
  url = ssh://machine2/~/settings
  fetch = +refs/heads/*:refs/remotes/machine2/*

Edit 3: Thank you very much for the answers. The result can be found in a separate blog post.

Answer 1

You can just pull. I.e. you have some new commits on machine A and now you are on machine B, then you just pull from A, like

git pull A

The git pull documentation has a lot of useful examples and usages including the use of remotes.

Answer 2

As mentioned, git pull is a good answer here. The pull command is essentially a combination of fetch and merge; the former will bring all of the remote commits into your repository as a (possibly new) branch, while the latter will merge that branch into your current branch. Of course, determining which branch will get the merge is a bit of a trick. In general, you have to configure this on a per-repository basis. Git does have a special case for when the branch currently checked-out is tracking a remote branch in the repository you pull from, and that remote branch is the only one which has changes, at which point Git will simply assume you want to merge the remote branch with the current one and do it automatically.

Aside from some rather opaque configuration, pull has some other issues with are worthy of mention. Most notably: it's tied to the merge command. In other words, if you pull in the remote changes and you have some changes of your own in your local branch, Git will be forced to perform a merge in order to unify the two branches. In principle, this is just fine, but it plays havoc with any rebasing you may want to do at some point in the future. You mentioned that your use case is three of your own computers. If I were you, I would try to keep my history in the same branch across the three as linear as possible. Don't merge machine A into machine B, rebase the changes of B on top of the changes of A to produce a single, linear history on that logical branch.

In order to do this, you will have to use the git fetch command directly, rather than working through pull. More specifically, you will want to do something like this:

git fetch A
git rebase A/master

Replace "A/master" with the name of the remote branch which you are tracking locally. Any changes in your local repository will be reparented on the head of A/master, giving you a linear history rather than one which diverges briefly only to merge a few commits later.