their per‐directory rules apply only on the sending side.  If the
              merge rule specifies sides to affect (via the s or r modifier  or
              both),  then  the rules in the file must not specify sides (via a
              modifier or a rule prefix such as hide).

       Per‐directory rules are inherited in all subdirectories of the directory
       where the merge‐file was found unless the ’n’ modifier was  used.   Each
       subdirectory’s  rules  are prefixed to the inherited per‐directory rules
       from its parents, which gives the newest rules a  higher  priority  than
       the  inherited rules.  The entire set of dir‐merge rules are grouped to‐
       gether in the spot where the merge‐file was specified, so it is possible
       to override dir‐merge rules via a rule that got specified earlier in the
       list of global rules.  When the list‐clearing rule ("!") is read from  a
       per‐directory  file,  it only clears the inherited rules for the current
       merge file.

       Another way to prevent a single rule from a dir‐merge  file  from  being
       inherited  is  to  anchor  it with a leading slash.  Anchored rules in a
       per‐directory merge‐file are relative to the merge‐file’s directory,  so
       a  pattern "/foo" would only match the file "foo" in the directory where
       the dir‐merge filter file was found.

       Here’s an example filter file which you’d specify via --filter=". file":

           merge /home/user/.global‐filter
           ‐ *.gz
           dir‐merge .rules
           + *.[ch]
           ‐ *.o
           ‐ foo*

       This will merge the contents of the  /home/user/.global‐filter  file  at
       the  start  of the list and also turns the ".rules" filename into a per‐
       directory filter file.  All rules read in prior to the start of the  di‐
       rectory  scan  follow  the  global anchoring rules (i.e. a leading slash
       matches at the root of the transfer).

       If a per‐directory merge‐file is specified with a path that is a  parent
       directory  of the first transfer directory, rsync will scan all the par‐
       ent dirs from that starting point to the transfer directory for the  in‐
       dicated  per‐directory file.  For instance, here is a common filter (see
       -F):

           ‐‐filter=’: /.rsync‐filter’

       That rule tells rsync to scan for the file .rsync‐filter in all directo‐
       ries from the root down through the parent  directory  of  the  transfer
       prior  to  the start of the normal directory scan of the file in the di‐
       rectories that are sent as a part of the transfer. (Note: for  an  rsync
       daemon, the root is always the same as the module’s "path".)

       Some examples of this pre‐scanning for per‐directory files:

           rsync ‐avF /src/path/ /dest/dir
           rsync ‐av ‐‐filter=’: ../../.rsync‐filter’ /src/path/ /dest/dir
           rsync ‐av ‐‐filter=’: .rsync‐filter’ /src/path/ /dest/dir

       The  first  two  commands above will look for ".rsync‐filter" in "/" and
       "/src" before the normal scan begins looking for the file in "/src/path"
       and its subdirectories.  The last command avoids the parent‐dir scan and
       only looks for the ".rsync‐filter" files in each  directory  that  is  a
       part of the transfer.

       If  you want to include the contents of a ".cvsignore" in your patterns,
       you should use the rule ":C", which creates a dir‐merge of  the  .cvsig‐
       nore  file,  but parsed in a CVS‐compatible manner.  You can use this to
       affect where the --cvs‐exclude (-C) option’s inclusion of the per‐direc‐
       tory .cvsignore file gets placed into your rules  by  putting  the  ":C"
       wherever  you  like in your filter rules.  Without this, rsync would add
       the dir‐merge rule for the .cvsignore file at the end of all your  other
       rules  (giving  it  a lower priority than your command‐line rules).  For