[RFC] Improvements to is_ignored.

[John Arbash Meinel]

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.

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.

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

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

John
=:->


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060130/5fc7d14d/attachment.pgp