source path, like this:

                  rsync ‐avR /foo/./bar/baz.c remote:/tmp/

              That would create /tmp/bar/baz.c on  the  remote  machine.  (Note
              that  the  dot must be followed by a slash, so "/foo/." would not
              be abbreviated.) For older rsync versions, you would need to  use
              a  chdir  to  limit  the  source path.  For example, when pushing
              files:

                  (cd /foo; rsync ‐avR bar/baz.c remote:/tmp/)

              (Note that the parens put the two commands into a  sub‐shell,  so
              that  the  "cd"  command doesn’t remain in effect for future com‐
              mands.) If you’re pulling files from an older rsync, use this id‐
              iom (but only for a non‐daemon transfer):

                  rsync ‐avR ‐‐rsync‐path="cd /foo; rsync" \
                       remote:bar/baz.c /tmp/

       --no‐implied‐dirs
              This option affects the default behavior of  the  --relative  op‐
              tion.  When it is specified, the attributes of the implied direc‐
              tories  from  the  source names are not included in the transfer.
              This means that the corresponding path elements on  the  destina‐
              tion system are left unchanged if they exist, and any missing im‐
              plied 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 the receiving 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 --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   --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 --keep‐
              dirlinks option (which will also affect symlinks  to  directories
              in the rest of the transfer).

              When  pulling  files from an rsync older than 3.0.0, you may need
              to use this option if the sending side has a symlink in the  path
              you  request  and  you  wish the implied directories to be trans‐
              ferred as normal directories.

       --backup, -b
              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
              --backup‐dir and --suffix options.

              If you don’t specify --backup‐dir:

              1.     the --omit‐dir‐times option will be forced on

              2.     the use of --delete  (without  --delete‐excluded),  causes
                     rsync to add a "protect" filter‐rule for the backup suffix
                     to  the  end  of all your existing filters that looks like
                     this: -f "P *~".  This rule prevents 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/exclu‐
              sion of *, the auto‐added rule would never be reached).

       --backup‐dir=DIR
              This  implies