mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2013-11-15 14:53:50 -04:00
commit 27bbdb1fe1
3 changed files with 41 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Incorrect_merge__44___direct_repos___40__2__41__/comment_2_8bc496226a977dbeeb1ce3f06122f1c2._comment Normal file
View file

@ -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.
"""]]

15
doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_3_8cdbb1fda506b9e53a0e9ab88b2569c1._comment Normal file
View file

@ -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.
"""]]

14
doc/bugs/Incorrect_merge___40__a_special_case__41__/comment_4_9d74e2854a5d77f0f793f56fa0cff9e2._comment Normal file
View file

@ -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..
"""]]