Ambiguity leads to different behaviour depending on the state of the filesystem.
$ touch src $ mv src dstWhat do you expect to happen? The result depends on what 'dst' is.
Note that there are 3 different outcomes. This makes it difficult to write scripts that work reliably. This gets even worse when 'src' is a directory, as demonstrated here:
$ rm -rf dst $ mkdir src $ mv src dst $ mkdir src $ mv src dst
If 'dst' doesn't exist, the first mv command will rename 'src' to 'dst'. The second mv command will create dst/src ! If you replace 'mkdir' with a command that creates a tree of files (like wget --mirror) suddenly instead of having a newer version, you now have two copies. The sharp edge here is that the second mv succeeds, which can trick you into thinking that it did case #1 above, not #3. Only if you run 'mkdir;mv' a third time, it will result in an error.
Notice that whenever you run ls -al' you see two entries: . and .. ? If you use these as your destination, your command becomes unambiguous. For example:
$ mkdir src $ mv src dst/.
$ update my tree of files in src/... $ rsync -n --archive --delete src/. dst/.
Since both src and dst arguments end in "/." it's completely unambiguous; you're making one directory tree mimic another. It will correctly grab all dot files or anything with a weird name; no need to try and create a glob for files like ".foo.rc". The src is guaranteed to be a directory, dst is guaranteed to be a directory. Zero ambiguity.
Two small caveats: