[[!comment format=mdwn
 username="http://joeyh.name/"
 ip="209.250.56.246"
 subject="comment 1"
 date="2013-11-14T17:06:50Z"
 content="""
I verify this bug. And it's specific to direct mode as you say. Here is a shell script which automates the proccess:

[[!format sh \"\"\"
#!/bin/sh
set -e
mkdir test
cd test
git init a

cd a
git annex init
git annex direct
touch firstfile
git annex add firstfile
git annex sync # think this was left out of recipe

cd ..

git clone a b
cd b
git annex direct
echo bbbb > f
git annex add f
git annex sync || true
cd ..
cd a
mkdir f
echo aaaa > f/f
git annex add f/f
git annex sync || true
cd ..
cd b
git annex sync
echo \"after merge:\"
ls
\"\"\"]]

At this point, b only has the file version of f; the directory form has been removed. (Syncing to a of course then does the same thing there.)

And from the trascript, we can see what's going on:

<pre>
Adding f/f
CONFLICT (directory/file): There is a directory with name f in HEAD. Adding f as f~refs_heads_synced_master
Automatic merge failed; fix conflicts and then commit the result.
(Recording state in git...)
f: needs merge
[master 0600854] git-annex automatic merge conflict fix

  Merge conflict was automatically resolved; you may want to examine the result.
</pre>

The problem seems to be that direct mode merge does not find the `f~refs_heads_synced_master` created by the merge, so fails to copy it from the temp merge tree into the work tree.

`Command.Sync.cleanConflictCruft` is relevant, but was only made to work in indirect mode, it seems.

----

Obviously, if someone runs into this bug and seems to lose data, they can get the data back by reverting the changes from the automatic merge. Direct mode does preserve file contents when removing them from the work tree in a merge.
"""]]