Recent comments posted to this site:

Git can actually push into a non-bare repository, so long as the branch you change there is not a checked out one. Pushing into remotes/$foo/master and remotes/$foo/git-annex would work, however determining the value that the repository expects for $foo is something git cannot do on its own. And of course you'd still have to git merge remotes/$foo/master to get the changes.

Yes, you still keep the non-bare repos as remotes when adding a bare repository, so git-annex knows how to get to them.

I've made git annex sync run the simple script above. Perhaps it can later be improved to sync all repositories.

Comment by http://joey.kitenet.net/ Sat Dec 10 19:43:04 2011

Thanks for the tips so far. I guess a bare-only repo helps, but as well is something that I don’t need (for my use case), any only have to do because git works like this.

Also, if I have a mobile device that I want to push to, then I’d have to have two repositories on the device, as I might not be able to reach my main bare repository when traveling, but I cannot push to the „real“ repo on the mobile device from my computer. I guess I am spoiled by darcs, which will happily push to a checked out remote repository, updating the checkout if possible without conflict.

If I introduce a central bare repository to push to and from; I’d still have to have the other non-bare repos as remotes, so that git-annex will know about them and their files, right?

I’d appreciate a "git annex sync" that does what you described (commit all, pull, merge, push). Especially if it comes in a "git annex sync --all" variant that syncs all reachable repositories.

Comment by http://www.joachim-breitner.de/ Sat Dec 10 16:28:29 2011

First, you need a bare git repository that you can push to, and pull from. This simplifies most git workflow.

Secondly, I use mr, with this in .mrconfig:

[DEFAULT]
lib =
        annexupdate() {
                git commit -a -m update || true
                git pull "$@"
                git annex merge
                git push || true
        }

[lib/sound]
update = annexupdate
[lib/big]
update = annexupdate

Which makes "mr update" in repositories where I rarely care about git details take care of syncing my changes.

I also make "mr update" do a "git annex get" of some files in some repositories that I want to always populate. git-annex and mr go well together. :)

Perhaps my annexupdate above should be available as "git annex sync"?

Comment by http://joey.kitenet.net/ Fri Dec 9 22:56:11 2011
Good idea! I've made git annex add recover when ran a second time.
Comment by http://joey.kitenet.net/ Wed Dec 7 20:54:51 2011

Ah - very good to know that recovery is easier than the method I used.

I wonder if it could be made a feature to automatically and safely recover/resume from an interrupted git add?

Doh! Total brain melt on my part. Thanks for the additional info. Not taking my time and reading things properly - kept assuming that the full remote pull failed due to the warning:

You asked to pull from the remote 'rss', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

Rookie mistake indeed.

The bug with newlines is now fixed.

Thought I'd mention how to clean up from interrupting git annex add. When you do that, it doesn't get a chance to git add the files it's added (this is normally done at the end, or sometimes at points in the middle when you're adding a lot of files). Which is also why fsck, whereis, and unannex wouldn't operate on them, since they only deal with files in git.

So the first step is to manually use git add on any symlinks.

Then, git commit as usual.

At that point, git annex unannex would get you back to your starting state.

Comment by http://joey.kitenet.net/ Tue Dec 6 17:08:37 2011

This only happens with the WORM backend (or possibly with SHA1E if the file's extension has a newline).

The problem is not the newline in the file, but the newline in the key generated for the file. It's probably best to just disallow such keys being created.

Comment by http://joey.kitenet.net/ Tue Dec 6 16:49:32 2011

You're taking a very long and strange way to a place that you can reach as follows:

git pull remote
git annex get .

Which is just as shown in getting file content.

In particular, "git pull remote" first fetches all branches from the remote, including the git-annex branch. When you say "git pull remote master", you're preventing it from fetching the git-annex branch. If for some reason you want the slightly longer way around, it is:

git pull remote master
git fetch remote git-annex
git annex get .

Or, eqivilantly but with less network connections:

git fetch remote
git merge remote/master
git annex get .

BTW, notice that this is all bog-standard git branch pulling stuff, not specific to git-annex in the least. Consult your extensive and friendly git documentation for details. :)

Comment by http://joey.kitenet.net/ Tue Dec 6 16:43:29 2011

Ah HA! Looks like I found the cause of this.

[matt@rss01:~/files/matt_ford]0> git annex add mhs
add mhs/Accessing_Web_Manager_V10.pdf ok
....
add mhs/MAHSC Costing Request Form Dual
Organisations - FINAL v20 Oct 2010.xls git-annex: unknown response from git cat-file refs/heads/git-annex:8d5/ed4/WORM-s568832-m1323164214--MAHSC Costing Request Form Dual missing

Spot the file name with a newline character in it! This causes the error message above. It seems that the files proceeding this badly named file are sym-linked but not registered.

Perhaps a bug?

Comments on this page are closed.