@Matthias git annex merge will do what you want, as long as you have git-annex 4.20130709 or newer.

The errMessage build failure is due to a new version of optparse-applicative. I've added support for it in git master.

I get exactly the same error message as Matthias when attempting the minimal Cabal install on openSUSE 12.2 (x86_64) Linux.

Is there a possibility to use the automatic merge logic without using "git annex sync"? I don't want to have the "synced"-branches, but the auto-conflict-resolution is very nice.

I followed the instructions and the invocation of

cabal install git-annex --bindir=$HOME/bin -f"-assistant -webapp -webdav -pairing -xmpp -dns"

resulted in the following error:

Test.hs:107:41: Not in scope: `errMessage'
Failed to install git-annex-5.20140306
cabal: Error: some packages failed to install:
git-annex-5.20140306 failed during the building phase. The exception was:
ExitFailure 1

I used the Haskell Platform for Mac OS X (10.8)

Some explanations in French on how to do: http://seenthis.net/messages/237648#message238202

Thansk @joeyh.name for your answer. Do you think this feature could be integrated into the git-annex assistant ?

@severo the web app does not support setting up that use case. However, you can make a non-bare clone of your repository onto a removable drive, and if you do the assistant will use it just the same as if you'd set up a removable drive using the webapp. Note that you will need to run git annex sync inside that repository in order to update the tree it displays.

I've made git annex metadata --key work.

I'll wait and see what you come up with your special remote and add something to the protocol later if it makes sense.

I'm hacking around with using metadata from an external special remote. Those work with keys, not files, so one option would be to add a GETMETADATA to the protocol. It also seems like it would not be too hard to add an option to "git annex metadata" to take a key rather than a file.