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

doc/bugs/git-annex_fix_not_noticing_file_renames.mdwn

@@ -0,0 +1,33 @@
+What steps will reproduce the problem?
+
+    ~$ mkdir testannex
+    ~$ cd testannex/
+    testannex$ git init
+    Initialized empty Git repository in /Users/ed/testannex/.git/
+    testannex$ git annex init "test annex"
+    init test annex ok
+    (Recording state in git...)
+    testannex$ echo "file1" > file1
+    testannex$ git annex add file1
+    add file1 (checksum...) ok
+    (Recording state in git...)
+    testannex$ mkdir directory
+    testannex$ mv file1 directory/
+    testannex$ cat directory/file1 
+    cat: directory/file1: No such file or directory
+    testannex$ git annex fix directory/file1
+    git-annex: directory/file1 not found
+
+
+What is the expected output? What do you see instead?
+
+    git annex fix should fix the symlink.  It looks like maybe it's *following* the symlink?
+
+What version of git-annex are you using? On what operating system?
+
+    checkout:  20d195f   compiled on OS X 10.7 using cabal.  
+
+Please provide any additional information below.
+
+    git annex assistant is not noticing file renames either.
+

doc/design/assistant/blog/day_147__direct_mode/comment_1_0bd69532afce9dc04e3d88bfd0aed4b2._comment

@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://lj.rossia.org/users/imz/"
+ ip="79.165.59.119"
+ subject=""removing"  vs drop"
+ date="2012-12-12T13:20:42Z"
+ content="""
+I don't understand the difference behind:
+
+> Removing objects also works (and puts back a broken symlink)
+
+and
+
+> \"drop\" won't work because they rely on the symlink to map back to the key.
+
+If a file is removed (its content, which is replaced by a symlink), then it's not present there, so effectively it should be counted as \"dropped\" at this place. So, removing a file without counting it as dropped is something inconsistent, isn't it? Do I misunderstand something?
+"""]]