-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).
+side. If a file needs to be transferred and its size on the receiver is
+the same or longer than the size on the sender, the file is skipped. This
+does not interfere with the updating of a file's non-content attributes
+(e.g. permissions, ownership, etc.) when the file does not need to be
+transferred, nor does it affect the updating of any non-regular files.
+Implies bf(--inplace),
+but does not conflict with bf(--sparse) (since it is always extending a
+file's length).
+
+dit(bf(--append-verify)) This works just like the bf(--append) option, but
+the existing data on the receiving side is included in the full-file
+checksum verification step, which will cause a file to be resent if the
+final verification step fails (rsync uses a normal, non-appending
+bf(--inplace) transfer for the resend).
+
+Note: prior to rsync 3.0.0, the bf(--append) option worked like
+bf(--append-verify), so if you are interacting with an older rsync (or the
+transfer is using a protocol prior to 30), specifying either append option
+will initiate an bf(--append-verify) transfer.
+
+dit(bf(--no-tweak)) If a corresponding source file and destination file
+are determined to have identical data (or symlink target path, etc.) but differ
+in preserved attributes, rsync's default behavior (which can be explicitly
+requested via bf(--tweak)) is to tweak the attributes of the destination file
+in place. bf(--no-tweak) makes rsync recreate the destination file instead.
+
+You can use bf(--no-tweak) to avoid the race inherent in
+bf(--no-tweak-hlinked) if the destination is subject to concurrent
+modification. It may also be useful to ensure that, if multiple attributes
+of the destination file need updating, the attributes visible at the
+destination path change simultaneously. (Caveat: In the current
+implementation, the abbreviated extended attributes of the recreated file
+may be set after it is moved into place.)
+
+This option conflicts with bf(--inplace) and with bf(--append) because those
+combinations don't make sense.
+
+dit(bf(--no-tweak-hlinked)) Like bf(--no-tweak) but only affects destination
+files that have more than one hard link.
+You can use bf(--no-tweak-linked) to safely update a backup that has files
+hard-linked from a previous backup if you are not worried about concurrent
+modification to the destination.
+
+This option currently conflicts with bf(--inplace) and bf(--append). In
+the future, it might selectively disable those options for multiply linked
+destination files.