diff --git a/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment b/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment
new file mode 100644
index 0000000000..3b13217790
--- /dev/null
+++ b/doc/forum/Wishlist__58___automatic_reinject/comment_1_6bf093f228353130e80e7a30bcf0075d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="try the --known argument"
+ date="2018-10-25T17:30:29Z"
+ content="""
+This works now, with the reinject `--known` argument.
+"""]]
diff --git a/doc/todo/copy_instead_of_rename_on_reinject.mdwn b/doc/todo/copy_instead_of_rename_on_reinject.mdwn
new file mode 100644
index 0000000000..1aa3274b52
--- /dev/null
+++ b/doc/todo/copy_instead_of_rename_on_reinject.mdwn
@@ -0,0 +1,34 @@
+The same way that [[git-annex-import]] has a `--duplicate` option,
+there should be a way to reinject content without dropping the
+original file.
+
+My use case is that I had imported content in the wrong git-annex
+repository, by mistake. Unaware of my mistake, I moved the files (now
+symlinks) to the proper git-annex repo, where I added them and where
+they (obviously) were broken. So I tried to fix that with reinject:
+
+    $ git annex reinject --known ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
+    reinject /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac 
+    git-annex: /home/anarcat/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac: rename: permission denied (Permission denied)
+    failed
+    (recording state in git...)
+    git-annex: reinject: 1 failed
+
+It *almost* worked but failed because it cannot rename the git-annex
+file on the other side. But worse, copying the file by hand does not 
+work either:
+
+    $ LANG=C cp ~/mp3/.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac ../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac
+    cp: cannot create regular file '../../../.git/annex/objects/xJ/K5/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac/SHA256E-s16309242--41eb375ac760bf8542bae1ec2bcfce9269f78302820bcc88904e76bab473181c.flac': Permission denied
+
+... obviously because the directory already exists and is not
+writable. The workaround is to create those directories if missing
+(`mkdir -p`) or change the mode if present (`chmod u+w`), then run
+`git-annex-fsck` which will fix those modes.
+
+Other than making reinject work against a fellow git-annex repository,
+I think this would be useful to avoid deleting files which might
+surprise users... I suggest using a logic similar to
+[[git-annex-import]] for consistency reasons.
+
+Thanks! -- [[anarcat]]