discussing ignore rules

[Jan Hudec]

On Thu, May 11, 2006 at 13:35:14 -0700, Wayne Davison wrote:
> 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.

That's much of an argument for actually not using DEFAULT_IGNORE at all, but
just using it to initialize the ignore property. New backup files don't come
in that often that projects could not manually add them when they appear and
it would have the advantage of fully reproducible behaviour.

> 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

First match is not defined. The properties are proposed as /sets/ of strings
-- which means unordered.

> 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.

Yes, it feels complicated. I'd think that keeping the default ignore list for
anything else than initializing the ignore list of a new project is not worth
the trouble. So then there is just never_ignore and ignore from config and
the tree ignore. First never_ignore (default and per-branch merged) is
applied and then all ignores.

It should be noted that the ignore matching is rather performance critical,
so it needs to be really fast, so I don't want more than two regexp matches
per file (currently it's one match per file and pattern, but I already have
the pattern combiner written).

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060511/fb01d360/attachment.pgp