You say you started the repo with "git init --shared" .. but what that's really meant for is bare repositories, which can have several users pushing into it, not a non-bare repository.

The strange mode on the directories "dr-x--S---" and files "-r--r-----" must be due to your umask setting though. My umask is 022 and the directories and files under .git/annex/objects are "drwxr-xr-x" and "-r--r--r--", which allows anyone to read them unless an upper directory blocks it -- and with this umask, none do unless I explicitly remove permissions from one to lock down a repository.

About mpd, the obvious fix is to run mpd not as a system user but as yourself. I put "@reboot mpd" in my crontab to do this.

Joey, thanks for you quick help! I'll try the manual haskell-platform install once I have quicker internet again, i.e. tomorrow.

And sorry for the mess-up; I splitted the post into two. Hope it's clearer now.

This is now about different build failure than the bug you reported, which was already fixed. Conflating the two is just confusing.

The error message about syb is because by using cabal-install on an Ubuntu system from 2010, you're mixing the very old versions of some haskell libraries in Ubuntu with the new versions cabal wants to install. The solution is to stop mixing two package management systems --

• Either install git-annex without using cabal, and use apt-get to install all its dependencies from Ubuntu, assuming your distribution has all the necessary haskell libraries packaged.
• Or apt-get remove ghc, and manually install a current version of The Haskell Platform and use cabal.

Well, lock could check for modifications and require --force to lose them. But the check could be expensive for large files.

But git annex lock is just a convenient way to run git checkout. And running git checkout or git reset --hard will lose your uncommitted file the same way obviously.

Perhaps the best fix would be to get rid of lock entirely, and let the user use the underlying git commands same as they would to drop modifications to other files. It would then also make sense to remove unlock, leaving only edit.

make clean and rebuild worked... Thank you

BTW, you'll want to "make clean", since the S3stub hack symlinks a file into place and it will continue building with S3stub even if you fix the problem until you clean.

Despite status listing S3 support, your git-annex is actually built with S3stub, probably because it failed to find the necessary S3 module at build time. Rebuild git-annex and watch closely, you'll see "** building without S3 support". Look above that for the error and fix it.

It was certianly a bug that it showed S3 as supported when built without it. I've fixed that.

Very cool! Thank you for the explanation.

Yes; git-annex uses the git-annex branch independently of the branch you have checked out. You may find internals interesting reading, but the short answer is it will work.

Okay, I see, but is git annex get --auto . going to import all those files from the work remote into my home if the master branch of that remote isn't merged?