discussing ignore rules

[Wayne Davison]

On Thu, May 11, 2006 at 09:05:17PM +0200, Jan Hudec wrote:
> Hm, that would mean that there would still be a default ignore list, no
> longer containg things like object files, but only various swap and lock
> files. The project would need a way to get rid of patterns from that if
> needed.

Good point.  I'm thinking of this as the second of two similar classes
of ignore overrides.  The first overrides a per-user choice, such as the
bazaar.conf file having this:

[DEFAULT]
ignore=,*

This tells bzr to ignore files that start with a comma.  The user may
want to override this for a single project in the branches.conf file:

[/some/path]
never_ignore=,*

Having this outside the versioned info seems appropriate for personal
ignore rules.

The second class of ignore overrides gets to your point: a project
overriding the new DEFAULT_IGNORE list.  Let's say that some project
wishes to version *.BAK files.  To do this, I'd imagine the addition of
a negated ignore pattern that is versioned with the project:

    bzr ignore --never '*.BAK'

The project could even choose to add never-ignore rules for the files
that they know they will always want, just to be very explicit (e.g.
"bzr ignore --never '*.c'") and to avoid any forward-compatibility
issues with future DEFAULT_IGNORE rules.

Perhaps these positive/negative ignore rules would be represented to the
user using a leading "- " for ignore rules, and a leading "+ " for
never-ignore rules.  That way, if the user edits the entire list of
rules in a text editor (using the wiki's suggested "bzr ignore --edit"
command), they would see something like this:

- generated.c
+ *.c
- *.o
- *.a
- ...

The first match we find in the list wins, so in this case the file
specifies that *.c files are generally versioned, but that one file in
particular, generated.c, is ignored.  Because of this, the order we
evaluate the rules internally needs to be carefully considered (and new
rules added by "bzr ignore" need to be added to the top?).  I think that
this is the best order of evaluation: (1) the user's branch overrides,
(2) the user's DEFAULT overrides, (3) the versioned ignore info for the
project, and (4) the DEFAULT_IGNORE list.  The config-file overrides
should have highest precedence because we want to give each end user
full control over how things work for them (and they can fix any
conflicts that their DEFAULT ignore rules cause by adding a per-branch
override).  For instance, imagine that a project says to never-ignore
*.c and I have ignore ,* in my config file.  If the project's rules take
precedence, a temp-file I created named ,foo.c would not be ignored.

This is all rather complicated.  I've changed my mind a couple times
while writing this as I contemplated the various issues involved, so if
you have a better solution, feel free to share it.

..wayne..