git-annex sync --content can sometimes do unncessary transfers when syncing with multiple remotes at the same time. Here is an example:

git-annex sync --content r2 r3
...
copy foo (to r2...)
ok
copy foo (to r3...)
ok
drop foo (from r2...) ok

git-annex wanted r3
anything
git-annex wanted r2
not copies=foo:1
git-annex group r3
foo

At the time sync decides to copy to the first repository, it legitimately wants the content. But once the content is also copied to the second repository, the first no longer wants it.

Perhaps this could be improved by sync simulating that the second copy has already happened, and seeing if the first repository still wants the content then.

But, bear in mind that the second repository may not be accessible currently. And indeed it may currently be located somewhere such that content can only reach it via the first repository. So if it decides to send to the second repository but not then to the first, it should still send to the first repository if it is unable to send to the second.

So essentially, this would reorder the list of repositories to work on from "r2 r3" to "r3 r2".

But, it's also possible to have this situation:

git-annex wanted r3
not copies=foo:1
git-annex wanted r2
not copies=foo:1
git-annex group r3
foo
git-annex group r2
foo

In that situation, git-annex sync --content r2 r3 will currently send content to r2 when it's accessible. Then r3 doesn't get a copy, and the copy remains on r2. If the list of repositories were reordered, that would change which repository ends up with the file. Which would be surprising since that configuration and order of repositories passed to sync is clear in its desired effect.

With the config above, there would be no need to reorder the list of repositories since it does not avoid excess work. Are there configs where reordering would avoid excess work, but would also change desired behavior (for the same file)? --Joey