Running git annex sync or using the assistant involves merging changes from elsewhere into your repository's currently checked out branch. This could lead to a merge conflict, perhaps because the same file got changed in two different ways. A nice feature is that these merge conflicts are automatically resolved, rather than leaving git in the middle of a conflicted merge, which would prevent further syncing from happening.

When a conflict occurs, there will be several messages printed about the merge conflict, and the file that has the merge conflict will be renamed, with ".variant-XXX" tacked onto it. So if there are two versions of file foo, you might end up with "foo.variant-AAA" and "foo.variant-BBB". It's then up to you to decide what to do with these two files. Perhaps you can manually combine them back into a single file. Or perhaps you choose to rename them to better names and keep two versions, or delete one version you don't want.

The "AAA" and "BBB" in the above example are essentially arbitrary (technically they are the MD5 checksum of the key). The automatic merge conflict resoltuion is designed so that if two or more repositories both get a merge conflict, and resolve it, the resolved repositories will not themselves conflict. This is why it doesn't use something nicer, like perhaps the name of the remote that the file came from.

How to customise git-annex conflict resolution behaviour, such that for example: change naming convention of conflicted files with suffix or prefix, move conflicted files to another directory structure, overwrite conflicted files from preferred content ...

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.
@Matthias git annex merge will do what you want, as long as you have git-annex 4.20130709 or newer.
Comment by http://joeyh.name/ Thu Mar 20 12:10:10 2014

As far as I observed, "git annex merge" only merges the "git-annex" branch. My wish is to have the conflict resolution from "git annex sync" in the "master" branch, but no automatic commit, such that the user can verify and possibly correct the merge. The proposed merge could go to the index. Consider the following scenario:

  1. We have repo A, B, and CENTRAL
  2. All three start with a root commit in "master" branch
  3. Then A commits a file "test.txt" with content "a" and syncs with CENTRAL
  4. Meanwhile, B commits "test.txt" with content "b"
  5. When B tries to sync with CENTRAL, the proposed conflict resolution having two files "test.txt-variantXXXX" and "test.txt-variantYYYY" should be staged in the index, but not committed yet.
  6. B can now commit a custom merge, e.g. with file content "ab".

The point is that I really like the conflict resolution, but still want to force the user to check the result.

@Matthias you need to install git-annex 4.20130709 or newer. Then git-annex merge will do what you want. As I said before.

As for committing the merge, you can always adjust the result after the fact and use git commit --amend.

Comment by http://joeyh.name/ Wed Mar 26 14:56:30 2014

@joeyh: This must be a misunderstanding of what I want. I use version 5.20140320. I can't find a workflow where "git annex merge" changes my master branch, it only updates the git-annex branch.

Thinking again of it after some time, I am basically fine with "git annex sync". The only thing I am uncomfortable with is that the automatic merge is pushed without review.

@Matthias, here is an example of git-annex merge updating the master branch from the synced/master branch that was pushed to it earlier:

joey@darkstar:~/tmp/test/2>git annex merge
merge git-annex (merging synced/git-annex into git-annex...)
ok
merge synced/master 
Updating 7942eee..1f3422e
Fast-forward
 new_file | 1 +
 1 file changed, 1 insertion(+)
 create mode 120000 new_file
ok

If you are having trouble with it somehow, I'd suggest filing a bug report.

Comment by http://joeyh.name/ Thu Apr 17 16:00:22 2014
Thanks Joey, I could construct a scenario where the auto-conflict-resolution was applied in the master branch.
Comments on this page are closed.