close wontfix
This commit is contained in:
parent
f48ac9527b
commit
0ae8f45ee5
1 changed files with 18 additions and 0 deletions
|
@ -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]]
|
||||
|
|
Loading…
Add table
Reference in a new issue