+(Note that the parens put the two commands into a sub-shell, so that the
+"cd" command doesn't remain in effect for future commands.)
+If you're pulling files, use this idiom (which doesn't work with an
+rsync daemon):
+
+quote(
+tt( rsync -avR --rsync-path="cd /foo; rsync" \ )nl()
+tt( remote:bar/baz.c /tmp/)
+)
+
+dit(bf(--no-implied-dirs)) This option affects the default behavior of the
+bf(--relative) option. When it is specified, the attributes of the implied
+directories from the source names are not included in the transfer. This
+means that the corresponding path elements on the destination system are
+left unchanged if they exist, and any missing implied directories are
+created with default attributes. This even allows these implied path
+elements to have big differences, such as being a symlink to a directory on
+one side of the transfer, and a real directory on the other side.
+
+For instance, if a command-line arg or a files-from entry told rsync to
+transfer the file "path/foo/file", the directories "path" and "path/foo"
+are implied when bf(--relative) is used. If "path/foo" is a symlink to
+"bar" on the destination system, the receiving rsync would ordinarily
+delete "path/foo", recreate it as a directory, and receive the file into
+the new directory. With bf(--no-implied-dirs), the receiving rsync updates
+"path/foo/file" using the existing path elements, which means that the file
+ends up being created in "path/bar". Another way to accomplish this link
+preservation is to use the bf(--keep-dirlinks) option (which will also
+affect symlinks to directories in the rest of the transfer).
+
+In a similar but opposite scenario, if the transfer of "path/foo/file" is
+requested and "path/foo" is a symlink on the sending side, running without
+bf(--no-implied-dirs) would cause rsync to transform "path/foo" on the
+receiving side into an identical symlink, and then attempt to transfer
+"path/foo/file", which might fail if the duplicated symlink did not point
+to a directory on the receiving side. Another way to avoid this sending of
+a symlink as an implied directory is to use bf(--copy-unsafe-links), or
+bf(--copy-dirlinks) (both of which also affect symlinks in the rest of the
+transfer -- see their descriptions for full details).
+
+dit(bf(-b, --backup)) With this option, preexisting destination files are
+renamed as each file is transferred or deleted. You can control where the
+backup file goes and what (if any) suffix gets appended using the
+bf(--backup-dir) and bf(--suffix) options.
+
+Note that if you don't specify bf(--backup-dir), (1) the
+bf(--omit-dir-times) option will be implied, and (2) if bf(--delete) is
+also in effect (without bf(--delete-excluded)), rsync will add a "protect"
+filter-rule for the backup suffix to the end of all your existing excludes
+(e.g. bf(-f "P *~")). This will prevent previously backed-up files from being
+deleted. Note that if you are supplying your own filter rules, you may
+need to manually insert your own exclude/protect rule somewhere higher up
+in the list so that it has a high enough priority to be effective (e.g., if
+your rules specify a trailing inclusion/exclusion of '*', the auto-added
+rule would never be reached).
+
+dit(bf(--backup-dir=DIR)) In combination with the bf(--backup) option, this
+tells rsync to store all backups in the specified directory on the receiving
+side. This can be used for incremental backups. You can additionally
+specify a backup suffix using the bf(--suffix) option
+(otherwise the files backed up in the specified directory
+will keep their original filenames).
+
+dit(bf(--suffix=SUFFIX)) This option allows you to override the default
+backup suffix used with the bf(--backup) (bf(-b)) option. The default suffix is a ~
+if no -bf(-backup-dir) was specified, otherwise it is an empty string.
+
+dit(bf(-u, --update)) This forces rsync to skip any files which exist on
+the destination and have a modified time that is newer than the source
+file. (If an existing destination file has a modify time equal to the
+source file's, it will be updated if the sizes are different.)
+
+In the current implementation of bf(--update), a difference of file format
+between the sender and receiver is always
+considered to be important enough for an update, no matter what date
+is on the objects. In other words, if the source has a directory or a
+symlink where the destination has a file, the transfer would occur
+regardless of the timestamps. This might change in the future (feel
+free to comment on this on the mailing list if you have an opinion).
+
+dit(bf(--inplace)) This causes rsync not to create a new copy of the file
+and then move it into place. Instead rsync will overwrite the existing
+file, meaning that the rsync algorithm can't accomplish the full amount of
+network reduction it might be able to otherwise (since it does not yet try
+to sort data matches). One exception to this is if you combine the option
+with bf(--backup), since rsync is smart enough to use the backup file as the
+basis file for the transfer.
+
+This option is useful for transfer of large files with block-based changes
+or appended data, and also on systems that are disk bound, not network
+bound.
+
+The option implies bf(--partial) (since an interrupted transfer does not delete
+the file), but conflicts with bf(--partial-dir) and bf(--delay-updates).
+Prior to rsync 2.6.4 bf(--inplace) was also incompatible with bf(--compare-dest)
+and bf(--link-dest).
+
+WARNING: The file's data will be in an inconsistent state during the
+transfer (and possibly afterward if the transfer gets interrupted), so you
+should not use this option to update files that are in use. Also note that
+rsync will be unable to update a file in-place that is not writable by the
+receiving user.
+
+dit(bf(--append)) This causes rsync to update a file by appending data onto
+the end of the file, which presumes that the data that already exists on
+the receiving side is identical with the start of the file on the sending
+side. If that is not true, the file will fail the checksum test, and the
+resend will do a normal bf(--inplace) update to correct the mismatched data.
+Only files on the receiving side that are shorter than the corresponding
+file on the sending side (as well as new files) are sent.
+Implies bf(--inplace), but does not conflict with bf(--sparse) (though the
+bf(--sparse) option will be auto-disabled if a resend of the already-existing
+data is required).
+
+dit(bf(-d, --dirs)) Tell the sending side to include any directories that
+are encountered. Unlike bf(--recursive), a directory's contents are not copied
+unless the directory name specified is "." or ends with a trailing slash
+(e.g. ".", "dir/.", "dir/", etc.). Without this option or the
+bf(--recursive) option, rsync will skip all directories it encounters (and
+output a message to that effect for each one). If you specify both
+bf(--dirs) and bf(--recursive), bf(--recursive) takes precedence.