copy/move --from-anywhere --to remote
authorJoey Hess <joeyh@joeyh.name>
Thu, 30 Nov 2023 20:32:32 +0000 (16:32 -0400)
committerJoey Hess <joeyh@joeyh.name>
Thu, 30 Nov 2023 20:34:30 +0000 (16:34 -0400)
commit1e31bf81221d774fc26dac4fb15d722660dd0312
tree453f14a0d37e7014c4e601282d0b4ba96289ccdc
parent1654572bc1673103de88682eb4ab19dda2d1403c
copy/move --from-anywhere --to remote

Implementation was simple because it's equivilant to
--from=foo --to remote for each other remote, followed by
--to remote when there's a local copy.

(Or, in the edge case of --from-anywhere --to=here,
it's the same as --to=here.)

Note that, when the local repo does not have a copy,
fromToPerform gets it from a remote, sends it to the destination,
and drops the local copy. Another call to that for a second remote
will notice that the dest now has a copy, and simply drop from the
second remote, avoiding a second transfer.

Also note that, when numcopies doesn't allow dropping it from
everywhere, it will drop it from the cheapest remotes first
(maybe not ideal) up to more expensive remotes, and finally from the local
repo. So the local repo will generally end up holding a copy. Maybe not
ideal in all cases either, but it seems no worse to do that than to end up
with a copy undropped from a remote.

And I'm not entirely happy with the output, eg:

copy bigfile (from r3...) ok
copy bigfile ok

That makes sense if you think of the second line as being
the same as what is output by `git-annex copy bigfile --to bar`,
but it's less clear in this context. Maybe add "(from here...)"?
Also the --json output doesn't have a machine-readable field for
the "from" uuid, and maybe it should?

Sponsored-by: Dartmouth College's DANDI project
CHANGELOG
CmdLine/GitAnnex/Options.hs
Command/Copy.hs
Command/Move.hs
doc/bugs/copy_--from_--to_does_not_copy_if_present_locally/comment_6_c374eb44ea08f220dbcce5ecb88403fb._comment [new file with mode: 0644]
doc/git-annex-copy.mdwn
doc/git-annex-move.mdwn