+manpagesection(MERGE-FILE FILTER RULES)
+
+You can merge whole files into your filter rules by specifying either a
+merge (.) or a dir-merge (:) filter rule (as introduced in the FILTER RULES
+section above).
+
+There are two kinds of merged files -- single-instance ('.') and
+per-directory (':'). A single-instance merge file is read one time, and
+its rules are incorporated into the filter list in the place of the "."
+rule. For per-directory merge files, rsync will scan every directory that
+it traverses for the named file, merging its contents when the file exists
+into the current list of inherited rules. These per-directory rule files
+must be created on the sending side because it is the sending side that is
+being scanned for the available files to transfer. These rule files may
+also need to be transferred to the receiving side if you want them to
+affect what files don't get deleted (see PER-DIRECTORY RULES AND DELETE
+below).
+
+Some examples:
+
+quote(
+tt(merge /etc/rsync/default.rules)nl()
+tt(. /etc/rsync/default.rules)nl()
+tt(dir-merge .per-dir-filter)nl()
+tt(dir-merge,n- .non-inherited-per-dir-excludes)nl()
+tt(:n- .non-inherited-per-dir-excludes)nl()
+)
+
+The following modifiers are accepted after a merge or dir-merge rule:
+
+itemize(
+ it() A bf(-) specifies that the file should consist of only exclude
+ patterns, with no other rule-parsing except for in-file comments.
+ it() A bf(+) specifies that the file should consist of only include
+ patterns, with no other rule-parsing except for in-file comments.
+ it() A bf(C) is a way to specify that the file should be read in a
+ CVS-compatible manner. This turns on 'n', 'w', and '-', but also
+ allows the list-clearing token (!) to be specified. If no filename is
+ provided, ".cvsignore" is assumed.
+ it() A bf(e) will exclude the merge-file name from the transfer; e.g.
+ "dir-merge,e .rules" is like "dir-merge .rules" and "- .rules".
+ it() An bf(n) specifies that the rules are not inherited by subdirectories.
+ it() A bf(w) specifies that the rules are word-split on whitespace instead
+ of the normal line-splitting. This also turns off comments. Note: the
+ space that separates the prefix from the rule is treated specially, so
+ "- foo + bar" is parsed as two rules (assuming that prefix-parsing wasn't
+ also disabled).
+ it() You may also specify any of the modifiers for the "+" or "-" rules
+ (below) in order to have the rules that are read-in from the file
+ default to having that modifier set. For instance, "merge,-/ .excl" would
+ treat the contents of .excl as absolute-path excludes,
+ while "dir-merge,s .filt" and ":sC" would each make all their
+ per-directory rules apply only on the server side.
+)
+
+The following modifiers are accepted after a "+" or "-":
+
+itemize(
+ it() A "/" specifies that the include/exclude should be treated as an
+ absolute path, relative to the root of the filesystem. For example,
+ "-/ /etc/passwd" would exclude the passwd file any time the transfer
+ was sending files from the "/etc" directory.
+ it() A "!" specifies that the include/exclude should take effect if
+ the pattern fails to match. For instance, "-! */" would exclude all
+ non-directories.
+ it() A bf(C) is used to indicate that all the global CVS-exclude rules
+ should be inserted as excludes in place of the "-C". No arg should
+ follow.
+ it() An bf(s) is used to indicate that the rule applies to the sending
+ side. When a rule affects the sending side, it prevents files from
+ being transferred. The default is for a rule to affect both sides
+ unless bf(--delete-excluded) was specified, in which case default rules
+ become sender-side only. See also the hide (H) and show (S) rules,
+ which are an alternate way to specify server-side includes/excludes.
+ it() An bf(r) is used to indicate that the rule applies to the receiving
+ side. When a rule affects the receiving side, it prevents files from
+ being deleted. See the bf(s) modifier for more info. See also the
+ protect (P) and risk (R) rules, which are an alternate way to
+ specify receiver-side includes/excludes.
+)
+
+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 together 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 bf(--filter=". file":)
+
+quote(
+tt(merge /home/user/.global-filter)nl()
+tt(- *.gz)nl()
+tt(dir-merge .rules)nl()
+tt(+ *.[ch])nl()
+tt(- *.o)nl()
+)
+
+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 directory 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 parent
+dirs from that starting point to the transfer directory for the indicated
+per-directory file. For instance, here is a common filter (see bf(-F)):
+
+quote(tt(--filter=': /.rsync-filter'))
+
+That rule tells rsync to scan for the file .rsync-filter in all
+directories 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 directories 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:
+
+quote(
+tt(rsync -avF /src/path/ /dest/dir)nl()
+tt(rsync -av --filter=': ../../.rsync-filter' /src/path/ /dest/dir)nl()
+tt(rsync -av --filter=': .rsync-filter' /src/path/ /dest/dir)nl()
+)
+
+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 .cvsignore
+file, but parsed in a CVS-compatible manner. You can
+use this to affect where the bf(--cvs-exclude) (bf(-C)) option's inclusion of the
+per-directory .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
+example:
+
+quote(
+tt(cat <<EOT | rsync -avC --filter='. -' a/ b)nl()
+tt(+ foo.o)nl()
+tt(:C)nl()
+tt(- *.old)nl()
+tt(EOT)nl()
+tt(rsync -avC --include=foo.o -f :C --exclude='*.old' a/ b)nl()
+)
+
+Both of the above rsync commands are identical. Each one will merge all
+the per-directory .cvsignore rules in the middle of the list rather than
+at the end. This allows their dir-specific rules to supersede the rules
+that follow the :C instead of being subservient to all your rules. To
+affect the other CVS exclude rules (i.e. the default list of exclusions,
+the contents of $HOME/.cvsignore, and the value of $CVSIGNORE) you should
+omit the bf(-C) command-line option and instead insert a "-C" rule into
+your filter rules; e.g. "--filter=-C".
+
+manpagesection(LIST-CLEARING FILTER RULE)
+
+You can clear the current include/exclude list by using the "!" filter
+rule (as introduced in the FILTER RULES section above). The "current"
+list is either the global list of rules (if the rule is encountered while
+parsing the filter options) or a set of per-directory rules (which are
+inherited in their own sub-list, so a subdirectory can use this to clear
+out the parent's rules).
+
+manpagesection(ANCHORING INCLUDE/EXCLUDE PATTERNS)
+
+As mentioned earlier, global include/exclude patterns are anchored at the
+"root of the transfer" (as opposed to per-directory patterns, which are
+anchored at the merge-file's directory). If you think of the transfer as
+a subtree of names that are being sent from sender to receiver, the
+transfer-root is where the tree starts to be duplicated in the destination
+directory. This root governs where patterns that start with a / match.
+
+Because the matching is relative to the transfer-root, changing the
+trailing slash on a source path or changing your use of the bf(--relative)
+option affects the path you need to use in your matching (in addition to
+changing how much of the file tree is duplicated on the destination
+host). The following examples demonstrate this.
+
+Let's say that we want to match two source files, one with an absolute
+path of "/home/me/foo/bar", and one with a path of "/home/you/bar/baz".
+Here is how the various command choices differ for a 2-source transfer:
+
+quote(
+ Example cmd: rsync -a /home/me /home/you /dest nl()
+ +/- pattern: /me/foo/bar nl()
+ +/- pattern: /you/bar/baz nl()
+ Target file: /dest/me/foo/bar nl()
+ Target file: /dest/you/bar/baz nl()
+)
+
+quote(
+ Example cmd: rsync -a /home/me/ /home/you/ /dest nl()
+ +/- pattern: /foo/bar (note missing "me") nl()
+ +/- pattern: /bar/baz (note missing "you") nl()
+ Target file: /dest/foo/bar nl()
+ Target file: /dest/bar/baz nl()
+)
+
+quote(
+ Example cmd: rsync -a --relative /home/me/ /home/you /dest nl()
+ +/- pattern: /home/me/foo/bar (note full path) nl()
+ +/- pattern: /home/you/bar/baz (ditto) nl()
+ Target file: /dest/home/me/foo/bar nl()
+ Target file: /dest/home/you/bar/baz nl()
+)
+
+quote(
+ Example cmd: cd /home; rsync -a --relative me/foo you/ /dest nl()
+ +/- pattern: /me/foo/bar (starts at specified path) nl()
+ +/- pattern: /you/bar/baz (ditto) nl()
+ Target file: /dest/me/foo/bar nl()
+ Target file: /dest/you/bar/baz nl()
+)
+
+The easiest way to see what name you should filter is to just
+look at the output when using bf(--verbose) and put a / in front of the name
+(use the bf(--dry-run) option if you're not yet ready to copy any files).
+
+manpagesection(PER-DIRECTORY RULES AND DELETE)
+
+Without a delete option, per-directory rules are only relevant on the
+sending side, so you can feel free to exclude the merge files themselves
+without affecting the transfer. To make this easy, the 'e' modifier adds
+this exclude for you, as seen in these two equivalent commands:
+
+quote(
+tt(rsync -av --filter=': .excl' --exclude=.excl host:src/dir /dest)nl()
+tt(rsync -av --filter=':e .excl' host:src/dir /dest)nl()
+)
+
+However, if you want to do a delete on the receiving side AND you want some
+files to be excluded from being deleted, you'll need to be sure that the
+receiving side knows what files to exclude. The easiest way is to include
+the per-directory merge files in the transfer and use bf(--delete-after),
+because this ensures that the receiving side gets all the same exclude
+rules as the sending side before it tries to delete anything:
+
+quote(tt(rsync -avF --delete-after host:src/dir /dest))