[[!comment format=mdwn
 username="joey"
 subject="""comment 5"""
 date="2018-04-10T22:39:30Z"
 content="""
Another way to approach this is: `move` should not make
a situation worse, but is not required to make it better.

That would allow moving a file from A to B when numcopies wants 2 copies
but only one copy exists, because the file being on B is no worse than it
being on A.

But, if B already has a copy of the file, move would error rather than the
current behavior of removing from A, when numcopies wants two copies.

And, if B is untrusted (and A is not), or A has the file as required
content, moving to B would also error, as in both situations it makes
things worse.

This seems better than the ideas above, because it keeps move a somewhat
lowlevel operation, like it always has been, but no longer an unsafe one.
It matches many of my uses of move, when perhaps I want more copies than I
have, but can't currently spare the space (or am moving the file to a repo
that will later let it get replicated elsewhere).

It also means that after `git annex move --from`, the local repository will 
always have the file present, rather than move sometimes failing before
getting it due to numcopies. (And the converse with `--to`.)

I think this is a small enough change from the current behavior of move
that it can get away with not having a transition plan.
"""]]
