+You have your choice of using either short or long RULE names, as described
+below. If you use a short-named rule, the ',' separating the RULE from the
+MODIFIERS is optional. The PATTERN or FILENAME that follows (when present)
+must come after either a single space or an underscore (_).
+Here are the available rule prefixes:
+
+quote(
+bf(exclude, -) specifies an exclude pattern. nl()
+bf(include, +) specifies an include pattern. nl()
+bf(merge, .) specifies a merge-file to read for more rules. nl()
+bf(dir-merge, :) specifies a per-directory merge-file. nl()
+bf(hide, H) specifies a pattern for hiding files from the transfer. nl()
+bf(show, S) files that match the pattern are not hidden. nl()
+bf(protect, P) specifies a pattern for protecting files from deletion. nl()
+bf(risk, R) files that match the pattern are not protected. nl()
+bf(clear, !) clears the current include/exclude list (takes no arg) nl()
+)
+
+When rules are being read from a file, empty lines are ignored, as are
+comment lines that start with a "#".
+
+Note that the bf(--include)/bf(--exclude) command-line options do not allow the
+full range of rule parsing as described above -- they only allow the
+specification of include/exclude patterns plus a "!" token to clear the
+list (and the normal comment parsing when rules are read from a file).
+If a pattern
+does not begin with "- " (dash, space) or "+ " (plus, space), then the
+rule will be interpreted as if "+ " (for an include option) or "- " (for
+an exclude option) were prefixed to the string. A bf(--filter) option, on
+the other hand, must always contain either a short or long rule name at the
+start of the rule.
+
+Note also that the bf(--filter), bf(--include), and bf(--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 bf(--filter) option, or
+the bf(--include-from)/bf(--exclude-from) options.
+
+manpagesection(INCLUDE/EXCLUDE PATTERN RULES)
+
+You can include and exclude files by specifying patterns using the "+",
+"-", etc. filter rules (as introduced in the FILTER RULES section above).
+The include/exclude rules each specify a pattern that is matched against
+the names of the files that are going to be transferred. These patterns
+can take several forms:
+
+itemize(
+ it() if the pattern starts with a / then it is anchored to a
+ particular spot in the hierarchy of files, otherwise it is matched
+ against the end of the pathname. This is similar to a leading ^ in
+ regular expressions.
+ Thus "/foo" would match a file named "foo" at either the "root of the
+ transfer" (for a global rule) or in the merge-file's directory (for a
+ per-directory rule).
+ An unqualified "foo" would match any file or directory named "foo"
+ anywhere in the tree because the algorithm is applied recursively from
+ the
+ top down; it behaves as if each path component gets a turn at being the
+ end of the file name. Even the unanchored "sub/foo" would match at
+ any point in the hierarchy where a "foo" was found within a directory
+ named "sub". See the section on ANCHORING INCLUDE/EXCLUDE PATTERNS for
+ a full discussion of how to specify a pattern that matches at the root
+ of the transfer.
+ it() if the pattern ends with a / then it will only match a
+ directory, not a file, link, or device.
+ it() rsync chooses between doing a simple string match and wildcard
+ matching by checking if the pattern contains one of these three wildcard
+ characters: '*', '?', and '[' .
+ it() a '*' matches any non-empty path component (it stops at slashes).
+ it() use '**' to match anything, including slashes.
+ it() a '?' matches any character except a slash (/).
+ it() a '[' introduces a character class, such as [a-z] or [[:alpha:]].
+ it() in a wildcard pattern, a backslash can be used to escape a wildcard
+ character, but it is matched literally when no wildcards are present.
+ it() if the pattern contains a / (not counting a trailing /) or a "**",
+ then it is matched against the full pathname, including any leading
+ directories. If the pattern doesn't contain a / or a "**", then it is
+ matched only against the final component of the filename.
+ (Remember that the algorithm is applied recursively so "full filename"
+ can actually be any portion of a path from the starting directory on
+ down.)
+ it() a trailing "dir_name/***" will match both the directory (as if
+ "dir_name/" had been specified) and all the files in the directory
+ (as if "dir_name/**" had been specified). (This behavior is new for
+ version 2.6.7.)
+)
+
+Note that, when using the bf(--recursive) (bf(-r)) option (which is implied by
+bf(-a)), every subcomponent of every path is visited from the top down, so
+include/exclude patterns get applied recursively to each subcomponent's
+full name (e.g. to include "/foo/bar/baz" the subcomponents "/foo" and
+"/foo/bar" must not be excluded).
+The exclude patterns actually short-circuit the directory traversal stage
+when rsync finds the files to send. If a pattern excludes a particular
+parent directory, it can render a deeper include pattern ineffectual
+because rsync did not descend through that excluded section of the
+hierarchy. This is particularly important when using a trailing '*' rule.
+For instance, this won't work:
+
+quote(
+tt(+ /some/path/this-file-will-not-be-found)nl()
+tt(+ /file-is-included)nl()
+tt(- *)nl()
+)
+
+This fails because the parent directory "some" is excluded by the '*'
+rule, so rsync never visits any of the files in the "some" or "some/path"
+directories. One solution is to ask for all directories in the hierarchy
+to be included by using a single rule: "+ */" (put it somewhere before the
+"- *" rule), and perhaps use the bf(--prune-empty-dirs) option. Another
+solution is to add specific include rules for all
+the parent dirs that need to be visited. For instance, this set of rules
+works fine:
+
+quote(
+tt(+ /some/)nl()
+tt(+ /some/path/)nl()
+tt(+ /some/path/this-file-is-found)nl()
+tt(+ /file-also-included)nl()
+tt(- *)nl()
+)
+
+Here are some examples of exclude/include matching: