[RFC] Improvements to is_ignored.

[Jan Hudec]

On Mon, Jan 30, 2006 at 07:24:13 -0600, John Arbash Meinel wrote:
> Martin Pool wrote:
> > On 30 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> 
> ...
> 
> > But the question is, *what* behaviour is retained?  If someone asks to
> > ignore '*.c' do they really want that to be changed into '(*|.*).c'
> > because we used to suffer that bug from fnmatch?
> 
> I'm still not convinced that '*.c' shouldn't match .foo.c. It isn't a
> big deal to me, though, so if someone cares we'll do it that way.

Perhaps we can tell users what the changes mean during the conversion,
so they can choose what they want.

> That said, I personally am not very worried about that discrepancy. It
> is small, and only effects a few files.
> I'm more concerned about including default globs. Since that has a much
> stronger effect.

Yes, I agree that this is the real problem.

> >>> A small amount of logic would be needed to move .bzrignore from being a
> >>> versioned file to versioned data in a branch upgrade - and (obviously?)
> >>> to warn if doing a commit that has a .bzrignore.
> >>>
> >>> I feel quite strongly though that this is not a trivial case to bypass
> >>> the general principle: tree ignore rules matter a great deal to some
> >>> folk, and if we can (and we can, with only modest effort) ovoid breaking
> >>> them, lets do so.
> >> Ok. I can see 3 ways to go:
> >>
> >> 1. Add some 'directives' in .bzrignore. So that new .bzrignore,
> >>    generated by first use of 'bzr ignore', would start with something
> >>    like:
> >>     #style shell
> >>     #defaults no
> >>    which would tell bzr to interpret the patterns as (more) shell
> >>    compatible and that defaults should not be added (because 'bzr
> >>    ignore' would splice them here).

I talked about this with Robert yesterday and we dismissed this idea.
The 'dead chickens' would be ugly.

> >> ... and the two already outlined above:
> >>
> >> 2. Add a revision property telling whether it uses new or old style
> >>    .bzrignore. If it was set to old, 'bzr ignore' would upgrade
> >>    .bzrignore, add the default ignores and set it to new. is_ignored
> >>    would choose semantics based on it's value.
> >>
> >> 3. Make it versioned data, wholly under control of bzr. That's hardest
> >>    part, because it needs extending the 'bzr ignore' command to allow
> >>    full manipulation with the data (I'd like to see that anyway, but in
> >>    the other cases it can wait until later) and because it needs to add
> >>    the logic for handling that data.
> >>
> >> What do you folks think would be the best approach?
> >>
> >> I think 1. would be easiest, but complicate things for the user a bit.
> >> 2. should still be pretty easy. Perhaps the advantage of 3 would be that
> >> we won't have control files lying around the tree and that we could
> >> change the storage without impact on the user.
> > 
> > I think #1 is reasonable, though I would still want to ask whether
> > anyone actually wants the old buggy behaviour.
> 
> Just default globs for me.

The default globs could be well dealt with a revision property.

Robert suggested 3 on irc yesterday and I am inclined to think it's
indeed the right way. It means there won't be a control file with all
those patterns lying around all the time.  It will also mean more work
though and it will probably require running an editor on the list from
'bzr ignore'.

> > I see the question of whether this is stored in .bzrignore or in a
> > directory property or elsewhere as being somewhat orthogonal to how the
> > rules are interpreted.  Whereever it is stored, we have a choice of 
> > 
> >  - just interpreting using the current glob engine
> >  - rewriting rules into a new style
> >  - or putting in an indication of how they should be interpreted
> > 
> > It's somewhat useful for people to be able to comment out rules, or add
> > descriptive comments, which pushes me towards treating it as a
> > human-created source file, whereever it lives.
> 
> I agree that people would want to add descriptive comments. Partially
> that is because we have the ability to let them.
> 
> I think we should put a marker in the file, just to let us know whether
> we are including defaults or not.

Hm, this would again suggest 2 is best. Having a revision property
saying we added the default ignores.

-- 
						 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/20060131/f4ea7baf/attachment.pgp