Added a comment: analysis

1 files changed, 15 insertions, 0 deletions

diff --git a/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment b/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment
new file mode 100644
index 000000000..49210ee55
--- /dev/null
+++ b/doc/bugs/Merge_involving_symlink_yields_unexpected_results/comment_4_13179e0f72026092e48c13082818ce68._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.55"
+ subject="analysis"
+ date="2014-07-08T17:52:59Z"
+ content="""
+When resolveMerge' calls graftin to add A's file2 symlink to B's tree, it actually stages the right symlink (the non-annexed one).
+
+However, the work tree is left as-is, so it still has the annexed symlink in it. So git status shows file2 as modified. Later syncs will commit that.
+
+This is why the sync in A doesn't have the problem, as there things are the other way around, and git-annex makes the git-annex symlink, leaving the non-annexed symlink as-is in the work tree.
+
+So, graftin needs to update the work tree. But it's tricky because graftin is called in 3 situations: non-symlink file, directory, and non-annexed symlink.
+Interestingly, in the other 2 cases, git-merge already takes care of updating the work tree -- it deletes the annexed symlink and puts in place either the non-symlink file or the directory. It's only the the case of a merge conflict involving 2 symlinks that git merge doesn't update the tree in this way. It's nice to be able to rely on git-merge in the other 2 cases, especially the directory case (avoids having to manually check out the directory).
+"""]]