Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Machines A and B host a common git annex repository. They both have the git-annex program installed and I manually edit/commit/etc stuff on both machines. A & B are not connected to the internet at the same time, so they can't be synced together directly.

Server C is always on and connected (and free and pretty secure). It has git installed, but I don't have admin rights, so I can't install git-annex.

My question: Can I use Server C as a central hub to push and pull git-annex updates from both A and B, without having to install git-annex and the whole haskell ghc dependencies on C?

I tried using C with "directory" or "rsync" special remotes, but this seems to only hold files, not the rest of what's needed to update A and B after push/pulls.

Any hint would be much appreciated!

share|improve this question
up vote 6 down vote accepted

With git and rsync access to the same server you can use that server to store both the history (via git access) and the annex key-value store (via rsync access). These could also be decoupled and stored on any number of different servers.

It looks like you've already read up on all of the tools you'll need. Basically, you'll end up with 2 separate remotes, both pointing to different locations on server-c. The first remote (server-c) is a regular git remote for synchronizing your history and anything that is checked directly into the git repo. The second remote is an annex special remote.

[remote "server-c"]
    url =
    fetch = +refs/heads/*:refs/remotes/server-c/*
[remote "server-c-rsync"]
    annex-rsyncurl =
    annex-uuid = ...

You should be able to set this up with something along the lines of:

git remote add server-c
git annex initremote server-c-rsync type=rsync encryption=none

This should get you the basic functionality that you're looking for. The only downside is that you have 2 different remote names that really point to the same server. In particular you just have to remember to use the special remote (server-c-rsync) when using the --to= or --from= arguments of get, copy, and move.

It may be possible to point a single remote to both locations, however I'm not sure if this is actually supported. The following commands appear to create a sensible .git/config.

git init
git annex init "test"
git remote add server-c
git annex initremote server-c type=rsync encryption=none

For me this results in a single remote in .git/config with both a url= (for the normal git operations) and a annex-rsyncurl=. However, I have not tested this any further to ensure that git annex ignores the url and uses only the annex-rsyncurl entry when operating with annexed files.

share|improve this answer
Great! I'll do some testing, but this should get me pretty close to a workable solution. Thanks a lot for your time and answer! – Vincent Jan 2 '13 at 14:32
Glad I could help. I just started using git annex myself over the holiday break and so far I'm extremely happy with it! – Justin Geibel Jan 3 '13 at 3:04
i think the last example should just work. in fact, i think it would rsync files in place even if it's just a bare git repo... – anarcat Mar 31 '15 at 2:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .