Merge branch 'master' of ssh://git-annex.branchable.com

3 files changed, 41 insertions, 0 deletions

diff --git a/doc/bugs/Incorrect_merge__44___direct_repos___40__2__41__/comment_2_8bc496226a977dbeeb1ce3f06122f1c2._comment b/doc/bugs/Incorrect_merge__44___direct_repos___40__2__41__/comment_2_8bc496226a977dbeeb1ce3f06122f1c2._comment
new file mode 100644
index 000000000..f9d3c7ffe
--- /dev/null
+++ b/doc/bugs/Incorrect_merge__44___direct_repos___40__2__41__/comment_2_8bc496226a977dbeeb1ce3f06122f1c2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 2"
+ date="2013-11-15T17:39:37Z"
+ content="""
+My initial guess was wrong.. This is not actually a bug in conflicted merge resolution at all.
+
+The bug is that in direct mode, it diffs the old and new tree when doing a normal merge, so see what files in the work tree need to be changed. This was written to go through the diff and replay the deletes and adds. In this case, since f/f and f are different items, they can appear in either order in the diff But the code only worked when f was first deleted, and f/f was then added. And it turns out that in this case, the diff had the two items the other way around.
+
+So, I think it needs to do 2 passes, first deleting and then adding.
+"""]]
diff --git a/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_3_8cdbb1fda506b9e53a0e9ab88b2569c1._comment b/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_3_8cdbb1fda506b9e53a0e9ab88b2569c1._comment
new file mode 100644
index 000000000..ce5c144e1
--- /dev/null
+++ b/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_3_8cdbb1fda506b9e53a0e9ab88b2569c1._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 3"
+ date="2013-11-15T17:48:42Z"
+ content="""
+Hmm. In your script, when you run `git annex sync` in a and then `echo aaaa > f`, f already exists at that point as a symlink. This actually ends up following the link and writing to .git/annex/objects. (fsck will detect that junk has been written there)
+
+That's a bug on its own; seems like direct mode is neglecting to lock down the .git/annex/objects directories to prevent writing to them like this.
+
+----
+
+However, this means that your script does not demonstrate the bug you originally reported. 
+You remove b/f and sync, and since a/f has not been changed, the deleting is correctly synced to a, removing a/f.
+"""]]
diff --git a/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_4_9d74e2854a5d77f0f793f56fa0cff9e2._comment b/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_4_9d74e2854a5d77f0f793f56fa0cff9e2._comment
new file mode 100644
index 000000000..c7bb02765
--- /dev/null
+++ b/doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_4_9d74e2854a5d77f0f793f56fa0cff9e2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.246"
+ subject="comment 4"
+ date="2013-11-15T17:52:38Z"
+ content="""
+Looking back at the original bug description:
+
+\"repo A a symlink to a file whose contents aren't yet available, are overwritten, while at repo B the file is deleted.\"
+
+I think the \"overwritten\" is key. I suspect you were always doing echo > f where f was a symlink, and this does not actually overwrite the symlink, it just puts data (that fsck will reject) into the annex.
+
+So, proceeding as if the real bug here is the ability to write through symlink in direct mode, unless told otherwise..
+"""]]