struct exclude_list_struct {
--- orig/rsync.yo 2004-08-03 15:34:32
-+++ rsync.yo 2004-08-10 04:49:06
++++ rsync.yo 2004-08-10 05:19:45
@@ -335,6 +335,7 @@ verb(
--include=PATTERN don't exclude files matching PATTERN
--include-from=FILE don't exclude patterns listed in FILE
-0 --from0 all file lists are delimited by nulls
--version print version number
--daemon run as an rsync daemon
-@@ -979,15 +980,22 @@ The exclude and include patterns specifi
+@@ -979,24 +980,32 @@ The exclude and include patterns specifi
selection of which files to transfer and which files to skip.
Rsync builds an ordered list of include/exclude options as specified on
-The filenames matched against the exclude/include patterns are relative
-to the "root of the transfer". If you think of the transfer as a
+-subtree of names that are being sent from sender to receiver, the root
+-is where the tree starts to be duplicated in the destination directory.
+-This root governs where patterns that start with a / match (see below).
+The global include/exclude rules are anchored at the "root of the
+transfer" (as opposed to per-directory rules, which are anchored at
-+the current directory). If you think of the transfer as a
- subtree of names that are being sent from sender to receiver, the root
- is where the tree starts to be duplicated in the destination directory.
- This root governs where patterns that start with a / match (see below).
-@@ -996,7 +1004,7 @@ Because the matching is relative to the
++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 (as described in the list on pattern forms below).
+
+ Because the matching is relative to the transfer-root, changing the
trailing slash on a source path or changing your use of the --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
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".
-@@ -1043,23 +1051,29 @@ because rsync did not descend through th
+@@ -1043,23 +1052,27 @@ because rsync did not descend through th
hierarchy.
Note also that the --include and --exclude options take one pattern
-each. To add multiple patterns use the --include-from and
---exclude-from options or multiple --include and --exclude options.
+each. To add multiple patterns use the --include-from and --exclude-from
-+options or multiple --include and --exclude options. See also the
-+section on MERGED EXCLUDE FILES for how to merge-files together and
-+specify local rules within a hierarchy of files.
++options or multiple --include and --exclude options.
-The patterns can take several forms. The rules are:
+The include/exclude patterns can take several forms. The rules are:
+ against the end of the pathname. This is similar to a leading ^ in
+ regular expressions.
+ Thus "/foo" would match a file called "foo" at either the "root of the
-+ transfer" (for a global rule) or in the current directory (for a
++ 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
it() if the pattern ends with a / then it will only match a
directory, not a file, link, or device.
-@@ -1072,22 +1086,31 @@ itemize(
+@@ -1072,22 +1085,31 @@ itemize(
single asterisk pattern "*" will stop at slashes.
it() if the pattern contains a / (not counting a trailing /) or a "**"
)
The +/- rules are most useful in a list that was read from a file, allowing
-@@ -1134,10 +1157,109 @@ itemize(
+@@ -1134,10 +1156,111 @@ itemize(
it() --include "*/" --include "*.c" --exclude "*" would include all
directories and C source files
it() --include "foo/" --include "foo/bar.c" --exclude "*" would include
+You can merge whole files into an exclude file by specifying a rule that
+starts with a ". " (a dot followed by a space) and putting a filename in
+place of the pattern. There are two kinds of merged exclude files --
-+single-instance and per-directory. You select which one you want by
-+optionally including an option prior to the merge-file name:
++single-instance and per-directory. The choice is made via an option
++placed prior to the merge-file name:
+
+startdit()
+
+every directory that it traverses for the named file, merging its contents
+when the file exists.
+
-+Per-directory rules are inherited in all subdirectories of the directory
-+where the merge-file was found. Each subdirectory's rules are prefixed
-+to the inherited rules from the parent directories, which gives the
-+newest rules a higher priority than the inherited rules. If you don't
-+want a rule to be inherited, anchor it with a leading slash. Anchored
-+rules in a per-directory merge-file are relative to the current
-+directory, so a rule "/foo" would only exclude the file "foo" in the
-+directory where the per-dir exclude file was found.
-+
+dit(bf(--)) End the scanning of options. Useful if you want to specify a
+filename that begins with a dash.
+
+enddit()
+
-+Here's an example exclude file (which you'd specify via the normal
-+--exclude-from=FILE option):
++Per-directory rules are inherited in all subdirectories of the directory
++where the merge-file was found. Each subdirectory's rules are prefixed
++to the inherited rules from the parent directories, which gives the
++newest rules a higher priority than the inherited rules. The entire set
++of per-dir rules is grouped together in the spot where the merge-file was
++specified, so it is possible to override per-dir rules via a rule that
++got specified earlier in the list of global rules.
++
++If you don't want a per-dir rule to be inherited, anchor it with a leading
++slash. Anchored rules in a per-directory merge-file are relative to the
++merge-file's directory, so a rule "/foo" would only exclude the file "foo"
++in the directory where the per-dir exclude file was found.
++
++Here's an example exclude file which you'd specify via the normal
++--exclude-from=FILE option:
+
+verb(
+ . /home/user/.global_excludes
+start of the list and also turns the ".excl" filename into a per-directory
+exclude file. All the merged rules default to being exclude rules because
+an exclude statement was used to specify them. Rules read in from the
-+.global_excludes file are anchored just like all other global rules
-+(only per-directory rules that are read in once the transfer begins get
-+the current-dir anchoring).
++.global_excludes file are anchored just like all other global rules.
+
+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
+)
+
+That exclude tells rsync to scan for the file .rsync-excludes in all
-+directories from the root up through the source of the transfer. (For an
-+rsync daemon, the "root dir" is always the module's "path" setting.)
++directories from the root down through the source of the transfer. (For
++an rsync daemon, the "root dir" is always the module's "path" setting.)
+
+Some examples of this pre-scanning for per-directory files:
+
+Additionally, you can affect where the --cvs-exclude (-C) option's
+inclusion of the per-directory .cvsignore file gets placed into your rules
+by adding your own explicit per-directory merge rule for ".cvsignore".
-+Without this rsync would add its this rule at the end of all your other
++Without this, rsync would add its this rule at the end of all your other
+rules (giving it a lower priority than your command-line rules). For
+example:
+
Matt McCutchen's Web Site / rsync / rsync-patches.git / commitdiff