Due to popular demand, git-annex can now be used with bare repositories.
So, for example, you can stash a file away in the origin:
git annex move mybigfile --to origin
Of course, for that to work, the bare repository has to be on a system with git-annex-shell installed. If "origin" is on GitWeb, you still can't use git-annex to store stuff there.
It took a while, but bare repositories are now supported exactly as well as non-bare repositories. Except for these caveats:
git annex fsckworks in a bare repository, but does not display warnings about insufficient copies. To get those warnings, just run it in one of the non-bare checkouts.git annex unusedin a bare repository only knows about keys used in branches that have been pushed to the bare repository. So use it with care..- Commands that need a work tree, like
git annex addwon't work in a bare repository, of course. - However, you can run commands like
git annex copy,git annex get, andgit annex dropin a bare repository. In a bare repository, these behave as if the--alloption were used, and so operate on every single version of every single file that is present in the git repository history. The--branchoption can be used to make these commands only operate on the files referenced by a specified branch.
For example:git annex get --branch master
Here is a quick example of how to set this up, using origin as the remote name, and assuming ~/annex contains an annex:
On the server:
git init --bare bare-annex.git
cd bare-annex.git && git annex init origin
Now configure the remote and do the initial push:
cd ~/annex
git remote add origin example.com:bare-annex.git
git push origin master git-annex
Now git annex info should show the configured bare remote. If it does
not, you may have to pull from the remote first (older versions of
git-annex).
If you wish to configure git such that you can push/pull without arguments, set the upstream branch:
git branch master --set-upstream origin/master
I made a repository bare and later wanted to convert it, this would have worked with just plain git:
But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):
These instructions don't work for me, unfortunately.
This step:
results in:
Versions: git 1:1.9.1-1~bpo70+2 , git-annex 5.20141024~bpo70+1 (both packaged by Debian, same on local and remote)
And yes, I did a pull on the master branch first. Afraid to do anything with the git-annex branch without explicit instruction.
Since the two repos git-annex branches have diverged, you need to run
git annex mergeto merge them before you can push that branch.Of course,
git annex synchandles all that for you. It can be used against a bare repository as well as a non-bare.Well, no, i don't think they changed, unless i missed something: there shouldn't be a
.gitrepository there.There are various instructions on how to do this online. They do seem to agree with the first comment above.
Personnally, I would just
git cloneto a different repo andgit annex forgetthe old one. Unless you have a very complex repository with a lot of files, this is simple enough... You could even usegit annex reinitto recycle the previous uuid if that's a concern. So in short:git clone repo.git repo cd repo git annex info --fast # find the UUID of repo.git git annex move --from $UUID git annex reinit $UUID
Then
repo.gitcan be removed if you are certain everything is correct inrepo.Note that you may want to have backups of everything before you do anything, as usual.
Thanks Anarcat. I actually was dealing with a repository in direct mode, not bare mode. Only realised after today encountering one in bare mode, and reading internals. Your method worked too, but
would have been quicker I guess.
Are the synced/* branches necessary for a bare repo? Since there is no working directory, can't sync operate directly on the top level branches of choice, and avoid 'branch pollution'? Is it implemented this way just to simplify the code, or ...?
Also wondering if there is a practical difference between a bare repo and an rsync repo (other than storing the metadata, of course) - they both use rsync for transfer, no? Any speed/overhead/other differences to consider when choosing?
For my use case pertaining to question 2 I am using a local ARM NAS which works with the binary (plus S3 or gdrive remotes etc), but I figure why not spin up a private gitlab repo with metadata and no content since I want an off-site backup of the metadata anyways. Does a bare repo on a nas add anything here, vs an rsync remote? Perhaps just rsync is even better to avoid overhead on a tiny/slow NAS?
@scottgorlin bare git repositories cannot in general be detected when looking at a remote, so
git annex syncpicks a behavior that works whether a remote is a bare git repository or not.A bare repo and a rsync special remote should have pretty similar performance.