When rsync encountered an empty file list, it behaved differently

[rsync.git] / rsync.yo

diff --git a/rsync.yo b/rsync.yo
index 176fd235ebf57e0975c2f961470be062d0ad2b22..a23234e8e7573d7857f4829f241a78f7637e0f2f 100644 (file)
--- a/rsync.yo
+++ b/rsync.yo
@@ -139,6 +139,15 @@ tt(rsync -av /src/foo /dest)nl()
 tt(rsync -av /src/foo/ /dest/foo)nl()
 )
 
+Note also that host and module references don't require a trailing slash to
+copy the contents of the default directory.  For example, both of these
+copy the remote directory's contents into "/dest":
+
+quote(
+tt(rsync -av host: /dest)nl()
+tt(rsync -av host::module /dest)nl()
+)
+
 You can also use rsync in local-only mode, where both the source and
 destination don't have a ':' in the name. In this case it behaves like
 an improved copy command.
@@ -1276,17 +1285,24 @@ of zero specifies no limit.
 
 dit(bf(--write-batch=FILE)) Record a file that can later be applied to
 another identical destination with bf(--read-batch). See the "BATCH MODE"
-section for details.
+section for details, and also the bf(--only-write-batch) option.
 
 dit(bf(--only-write-batch=FILE)) Works like bf(--write-batch), except that
 no updates are made on the destination system when creating the batch.
 This lets you transport the changes to the destination system via some
-other means and then apply the changes via bf(--read-batch).  Note that
-you can feel free to write the batch directly to some portable media: if
-this media fills to capacity before the end of the transfer, you can just
-apply that partial transfer to the destination and repeat the whole process
-to get the rest of the changes (as long as you don't mind a partially
-updated destination system while the multi-update cycle is happening).
+other means and then apply the changes via bf(--read-batch).
+
+Note that you can feel free to write the batch directly to some portable
+media: if this media fills to capacity before the end of the transfer, you
+can just apply that partial transfer to the destination and repeat the
+whole process to get the rest of the changes (as long as you don't mind a
+partially updated destination system while the multi-update cycle is
+happening).
+
+Also note that you only save bandwidth when pushing changes to a remote
+system because this allows the batched data to be diverted from the sender
+into the batch file without having to flow over the wire to the receiver
+(when pulling, the sender is remote, and thus can't write the batch).
 
 dit(bf(--read-batch=FILE)) Apply all of the changes stored in FILE, a
 file previously generated by bf(--write-batch).