specifies an include pattern that (by default) is both a show and
              a risk.

       merge, ’.’
              specifies a merge‐file on the client side to read for more rules.

       dir‐merge, ’:’
              specifies  a per‐directory merge‐file.  Using this kind of filter
              rule requires that you trust the sending side’s filter  checking,
              so  it has the side‐effect mentioned under the --trust‐sender op‐
              tion.

       hide, ’H’
              specifies a pattern for hiding files from the transfer.   Equiva‐
              lent  to a sender‐only exclude, so -f’H foo’ could also be speci‐
              fied as -f’-s foo’.

       show, ’S’
              files that match the pattern are  not  hidden.  Equivalent  to  a
              sender‐only  include,  so  -f’S foo’  could  also be specified as
              -f’+s foo’.

       protect, ’P’
              specifies a pattern for protecting files from deletion.   Equiva‐
              lent to a receiver‐only exclude, so -f’P foo’ could also be spec‐
              ified as -f’-r foo’.

       risk, ’R’
              files  that  match the pattern are not protected. Equivalent to a
              receiver‐only include, so -f’R foo’ could also  be  specified  as
              -f’+r foo’.

       clear, ’!’
              clears the current include/exclude list (takes no arg)

       When  rules are being read from a file (using merge or dir‐merge), empty
       lines are ignored, as are whole‐line comments  that  start  with  a  ’#’
       (filename rules that contain a hash character are unaffected).

       Note  also  that the --filter, --include, and --exclude options take one
       rule/pattern each.  To add multiple ones, you can repeat the options  on
       the  command‐line,  use the merge‐file syntax of the --filter option, or
       the --include‐from / --exclude‐from options.

   PATTERN MATCHING RULES
       Most of the rules mentioned above take an argument that  specifies  what
       the  rule should match.  If rsync is recursing through a directory hier‐
       archy, keep in mind that each pattern is matched  against  the  name  of
       every  directory  in  the  descent  path as rsync finds the filenames to
       send.

       The matching rules for the pattern argument take several forms:

       o      If a pattern contains a / (not counting a trailing  slash)  or  a
              "**"  (which  can  match  a  slash),  then the pattern is matched
              against the full  pathname,  including  any  leading  directories
              within  the  transfer.   If  the  pattern doesn’t contain a (non‐
              trailing) / or a "**", then it is matched only against the  final
              component  of  the  filename  or pathname. For example, foo means
              that the final path component must be "foo" while  foo/bar  would
              match  the  last 2 elements of the path (as long as both elements
              are within the transfer).

       o      A pattern that ends with a / only matches a directory, not a reg‐
              ular file, symlink, or device.

       o      A pattern that starts with a / is anchored to the  start  of  the
              transfer  path  instead  of  the  end.   For  example, /foo/** or
              /foo/bar/** match only leading elements in the path.  If the rule
              is read from a per‐directory filter file, the transfer path being
              matched will begin at the level of the filter file instead of the
              top of the transfer.  See the section  on  ANCHORING  INCLUDE/EX‐
              CLUDE  PATTERNS for a full discussion of how to specify a pattern
              that matches at the root of the transfer.

       Rsync chooses between doing a simple string match and wildcard  matching
       by  checking if the pattern contains one of these three wildcard charac‐
       ters: ’*’, ’?’, and ’[’ :

       o      a ’?’ matches any