git annex move does not honor numcopies. It is the only
git-annex command to not honor numcopies by default.
This can be surprising, and it complicates git-annex's story about attempting to preserve numcopies since there's this exception on the side.
Also, git annex move --to untrusted-repo drops the local copy even if the
untrusted copy is the only remaining copy, which is another unique thing
about move.
Should git annex move --safe become the default, and git annex move
--unsafe be needed to get the current behavior?
(Note that the -u short option makes that easy enough to type for those
of us who have workflows using the current behavior.)
Such a change would break workflows, and potentially quite a lot of examples in the documentation might need to be updated. Although with the default numcopies=1, the move behavior would not change (except when moving onto an untrusted repository, ), which will limit the imact some.
There could be a transition period where move warns when run w/o --safe/--unsafe.
--Joey
If git-annex knows it isn't going to do what I've instructed (move the file), I think it should just fail the command immediately, rather than copying but not dropping.
You could make --safe fallback to copy (for those that want that behaviour) and --unsafe has the risky behaviour, but move should either do just that, move the file, or do nothing.
This definitely seems strange to me. i've been using git-annex for a long time, and I have never known
movewas unsafe by default. so I think that--safeshould definitely be made defautl.but beyond that, I wouldn't use
--unsafeas a new flag: we already have--forcefor--dropfor example, shouldn't we reuse that here as well?I agree with anarcat.
The core use case of git-annex is to maintain sets of known-good data. This function mainly relies on a directory structure, checksums, a defined minimum of copies, and tracking where they are. I would never have assumed that I would be able to get git-annex to go below the mincopies, at least not unless I was deep into the innards of git-annex and/or abusing --force or the like.
-- RichiH
Candyangel, thanks, failing is indeed the better thing to do than copying when it's not safe to move. That makes sense.
Also,
git annex moveshould honor required contents, and refuse to move content away from a repository that requires it.It would be ok to use --force instead of --unsafe, but it doesn't allow for a staged transition from --unsafe by default to --safe by default. But, if we decide a stanged transition is not needed, I would be inclined to use the --force.
Move failing in these situations seems less likely to badly break existing workflows than move leaving both copies would; the caller will see that git-annex errored, rather than it silently leaving extra copies. So perhaps a staged transition could be skipped.
Another way to approach this is:
moveshould 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.
"not making it worse" sounds like acceptable middle ground to me. If you are not erroring out, at least printing a warning would be good. OTOH, this easily gets hidden in a flood of message if you're moving more than just a few files.
Still, principle of least surprise would point towards not going against basic safety measures in any case.