From 0ae8f45ee5f39532466ac2a33f031859e988ff2c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 8 Feb 2022 13:03:58 -0400 Subject: [PATCH] close wontfix --- ...work_when_drop_cannot_possibly_succeed.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) 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 93e3451fcf..0489fe40d8 100644 --- 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]] -- 2.30.2