close wontfix

diff --git a/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn b/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
index 93e3451fcf22fc66fe3b59791edc5130e983e9c2..0489fe40d87eb24362775aa2df381cb9096a53dd 100644 (file)
--- a/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
+++ b/doc/bugs/unnecessary_work_when_drop_cannot_possibly_succeed.mdwn
@@ -10,3 +10,21 @@ content on remotes and immediately fail.
 
 A user reported a situation where this happened to a lot of files and
 caused rate limiting and slowed down git-annex sync. --[[Joey]]
+
+> I started to implement making `git-annex drop` check if it could
+> possibly succeed before starting locking content, and found that
+> it was complicating it with a lot of fairly redundant code.
+> 
+> And since this command is run usually by the user when they really
+> want to drop something, not in a more general situation like git-annex
+> sync is, it seems ok for it to do a little bit of extra work,
+> showing what remotes it's able to lock, before failing, even though it
+> was always going to fail in the end. And if the user wants it to avoid
+> that, they can use `--auto`, which already avoids doing anything when it
+> cannot succeed.
+> 
+> So, I've decided to leave git-annex drop as it is. But what about
+> git-annex sync? I tried it, and when there are not enough copies it does
+> not appear to try to drop at all. 
+> 
+> [[done]] --[[Joey]]