rsync problems from flist.c change

[Wayne Davison]

On Thu, Apr 22, 2004 at 01:06:58PM +0200, Kurt Hornik wrote:
> Is there a way of overriding the excludes from .cvsignore?

It depends on which one you mean.  The global ones are inserted into the
exclude list at the point they're mentioned.  For instance:

    rsync --include='*.tar.gz' -C from/ to

In the above command the include overrides all the default CVS exclude
rules and the excludes that were read from the $HOME/.cvsignore and
$CVSIGNORE sources because they come after the include in the list of
options.  If an exclude occurs in a local .cvsignore file, then there
is no current way to override it short of turning off --cvs-exclude and
switching all the desired rules over to a different option (e.g. by
using --exclude-from=FILE).  However, I'd like to see some way to make
this more flexible.

To see the complexity of the issue, consider an --exclude-from ruleset
like this:

    + */
    + *.[ch]
    - *

In this ruleset the includes are there just to override the '*'.  If
they also override the per-directory .cvsignore rules, those extra rules
would be completely ignored (e.g. non-CVS directories would be included
and generated .c and .h files as well).

One solution is to give the user the ability to specify an overriding
include, such as a new '&' idiom that the perdir-exclude-from.diff (in
the patches dir) implements: "& *.tar.gz".  However, there may be a
better way to go.

An idea I just thought of is to allow the user to tell us where in the
hierarchy of rules the locally-read rules get put.  For instance, if we
introduce a new ". FILE" idiom, the user can tell us where the
.cvsignore file goes in the order of things:

    . .cvsignore
    + */
    + *.[ch]
    - *

That would probably be its default position, so the above would be
redundant if -C were specified.  It would then be possible to override
a local .cvsignore rule by putting it after an overriding rule:

    rsync --include='*.tar.gz' --include='. .cvsignore' -C from/ to

The nice thing about this idea is that it could also implement the
--perdir-exclude-from=FILE idiom without such an unwieldy option name.
The user could just mention a different local filename in the normal
list of include/exclude values:

    + *.tar.gz
    . .local_rules
    - some_file

I like this idea a lot.

..wayne..