Added a comment

1 files changed, 67 insertions, 0 deletions

diff --git a/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment b/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment
new file mode 100644
index 000000000..693f967cf
--- /dev/null
+++ b/doc/todo/inject_on_import/comment_1_314de82da94f47539e754e9bec950d7b._comment
@@ -0,0 +1,67 @@
+[[!comment format=mdwn
+ username="Xyem"
+ subject="comment 1"
+ date="2015-03-20T10:51:59Z"
+ content="""
+I just tested this and git-annex does not act according to its documentation.
+
+    ## git init annex
+    Initialized empty Git repository in ./annex/.git/
+    ## mkdir to_import
+    mkdir: created directory ‘to_import’
+    ## echo A > annex/A
+    ## echo B > annex/B
+    ## echo A > to_import/A
+    ## echo B > to_import/B
+    ## echo C > to_import/C
+    ## cd annex/
+    ## git annex init
+    init  ok
+    (Recording state in git...)
+    ## git annex add .
+    add A ok
+    add B ok
+    (Recording state in git...)
+    ## git commit -m \"commit\"
+    [master (root-commit) f2628f0] commit
+     2 files changed, 2 insertions(+)
+     create mode 120000 A
+     create mode 120000 B
+
+    ## git annex drop B --force
+    drop B ok
+    (Recording state in git...)
+
+Annex knows about A and B, A is present but B is not.
+
+to_import contains A, B and C.
+
+    ## git annex import --deduplicate ../to_import/
+    import to_import/C ok
+    import to_import/A (duplicate) ok
+    import to_import/B ok
+    (Recording state in git...)
+    ## ls -R
+    .:
+    A  B  to_import
+    
+    ./to_import:
+    B  C
+
+According to the docs, it would look like this:
+
+    ## ls -R
+    .:
+    A  B  to_import
+    
+    ./to_import:
+    C
+
+and B would be a dangling symlink (due to the content having been seen by the annex before, but not present).
+
+So '--import --deduplicate' actually imports/deduplicates files whose content /is not present/ in the annex, rather than 'has not been seen before'.
+
+Fortunately, this error is on the side of caution and data is never lost, but you do end up with duplicates (2 symlinks pointing to the same content).
+
+The behaviour is acceptable (to me at least, better duplicate symlinks than lost data), but the documentation is misleading and should probably refer to content presence rather than having ever been present.
+"""]]