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 fsck
works 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 unused
in 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 add
won't work in a bare repository, of course. - However, you can (with recent versions of git-annex) run
git annex copy
,git annex get
, andgit annex move
in a bare repository. These behave as if the--all
option were used, and just operate on every single version of every single file that is present in the git repository history.
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 merge
to merge them before you can push that branch.Of course,
git annex sync
handles 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
.git
repository 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 clone
to a different repo andgit annex forget
the old one. Unless you have a very complex repository with a lot of files, this is simple enough... You could even usegit annex reinit
to 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.git
can 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.