--to and --from seem to have different semantics than --source and --destination. Subtle, but still different.

That being said, I am not sure --from and --to are needed at all. Calling the local repo . and all remotes by their name, they are arguably redundant and removing them would make the syntax a lot prettier; mv and cp don't need them, either.

I am not sure changing syntax at this point is considered good style though personally, I wouldn't mind adapting and would actually prefer it over using --to and --from.

-v and -q would be nice.

Richard

Let's see..

• -v is already an alias for --verbose

• I don't find --source and --destination as easy to type or as clear as --from or --to.

• -F is fast, so it cannot be used for --force. And I have no desire to make it easy to mistype a short option and enable --force; it can lose data.

@richard while it would be possible to support some syntax like "git annex copy . remote"; what is it supposed to do if there are local files named foo and bar, and a remotes named foo and bar? Does "git annex copy foo bar" copy file foo to remote bar, or file bar from remote foo? I chose to use --from/--to to specify remotes independant of files to avoid such ambiguity, which plain old cp doesn't have since it's operating entirely on filesystem objects, not both filesystem objects and abstract remotes.

Seems like nothing to do here. done --Joey

Good point. scp fixes this by using a colon, but as colons aren't needed in git-annex remotes' names... -- RichiH