the way
       down to that file are excluded or else the file will never be discovered
       to be included. As an example, if the directory "a/path" was given as  a
       transfer   argument   and   you   want   to   ensure   that   the   file
       "a/path/down/deep/wanted.txt" is a part of the transfer, then the sender
       must  not  exclude   the   directories   "a/path",   "a/path/down",   or
       "a/path/down/deep" as it makes it way scanning through the file tree.

       When  you  are  working  on the rules, it can be helpful to ask rsync to
       tell you what is being  excluded/included  and  why.   Specifying  --de‐
       bug=FILTER  or (when pulling files) -M--debug=FILTER turns on level 1 of
       the FILTER debug information that will output a message any time that  a
       file  or  directory  is  included or excluded and which rule it matched.
       Beginning in 3.2.4 it will also warn  if  a  filter  rule  has  trailing
       whitespace,  since an exclude of "foo " (with a trailing space) will not
       exclude a file named "foo".

       Exclude and include rules can specify wildcard  PATTERN  MATCHING  RULES
       (similar  to shell wildcards) that allow you to match things like a file
       suffix or a portion of a filename.

       A rule can be limited to only affecting a directory by putting a  trail‐
       ing slash onto the filename.

   SIMPLE INCLUDE/EXCLUDE EXAMPLE
       With the following file tree created on the sending side:

           mkdir x/
           touch x/file.txt
           mkdir x/y/
           touch x/y/file.txt
           touch x/y/zzz.txt
           mkdir x/z/
           touch x/z/file.txt

       Then  the  following rsync command will transfer the file "x/y/file.txt"
       and  the  directories  needed  to  hold  it,  resulting  in   the   path
       "/tmp/x/y/file.txt" existing on the remote host:

           rsync ‐ai ‐f’+ x/’ ‐f’+ x/y/’ ‐f’+ x/y/file.txt’ ‐f’‐ *’ x host:/tmp/

       Aside:  this  copy could also have been accomplished using the -R option
       (though the 2 commands behave differently if deletions are enabled):

           rsync ‐aiR x/y/file.txt host:/tmp/

       The following command does not need an include of the "x" directory  be‐
       cause it is not a part of the transfer (note the traililng slash).  Run‐
       ning  this command would copy just "/tmp/x/file.txt" because the "y" and
       "z" dirs get excluded:

           rsync ‐ai ‐f’+ file.txt’ ‐f’‐ *’ x/ host:/tmp/x/

       This command would omit the zzz.txt file while copying  "x"  and  every‐
       thing else it contains:

           rsync ‐ai ‐f’‐ zzz.txt’ x host:/tmp/

   FILTER RULES WHEN DELETING
       By default the include & exclude filter rules affect both the sender (as
       it creates its file list) and the receiver (as it creates its file lists
       for  calculating  deletions).  If no delete option is in effect, the re‐
       ceiver skips creating the delete‐related file lists.  This two‐sided de‐
       fault can be manually overridden so that you are only specifying  sender
       rules  or receiver rules, as described in the FILTER RULES IN DEPTH sec‐
       tion.

       When deleting, an exclude protects a file from being removed on the  re‐
       ceiving  side  while  an  include overrides that protection (putting the
       file at risk of deletion). The default is for a file to  be  at  risk --
       its safety depends on it matching a corresponding file from the sender.

       An  example  of  the  two‐sided exclude effect can be illustrated by the
       copying of a C development directory between 2 systems.   When  doing  a
       touch‐up  copy,  you might want to skip copying the built executable and
       the .o files (sender hide) so that the receiving side  can  build  their
       own  and  not  lose  any object files that are already correct (receiver
       protect).  For instance:

           rsync ‐ai ‐‐del ‐f’‐ *.o’ ‐f’‐ cmd’