[RFC] Improvements to is_ignored.

[Martin Pool]

On 21 Jan 2006, Robert Collins <robertc at robertcollins.net> wrote:
> On Sat, 2006-01-21 at 10:57 +1100, Martin Pool wrote:
> > On 20 Jan 2006, Jan Hudec <bulb at ucw.cz> wrote:
> > > Hello All,
> > > 
> > > I have added some tests on my improvements to is_ignored. 
> 
> > > I actually think the difference will matter far less than it seems. They only
> > > affect three cases, all of which I think are minimally used:
> > >   * There is an absolute path containing * that should match over /
> > >     - Since ignored directories are not searched, usually only the directory
> > >       name is given, which does not contain wildcards most of the time.
> > >   * There are .-files in the tree that should be matched with a pattern
> > >     starting with * or ?.
> > >     - If .-files are present, they usually have their own rules and different
> > >       extension anyway.
> > >   * Non-ascii filenames are present and matched.
> > >     - Given that the charset was not defined and relied on the default
> > >       conversion, which is usually ascii, it's unlikely anyone did that.
> > >       I don't even think it worked.
> > 
> > I would tend to agree that they're unlikely to be relied upon.  In
> > general I don't think we need to have an option to support old buggy
> > behaviour just in case someone relied on it.
> > 
> > The changes should be in the Changes section of the news file, and there
> > should be more description in tutorial.txt.
> 
> The problem is that the file in revision 1 is that way forever. Theres
> no way the user can correct what they committed such that checkouts work
> again. So I think its important we preserve that behaviour when someone
> checks out an old revision, OR migrate this control data outside of the
> users file space asap.

I agree with the general principle (we should put it on the wiki
somewhere).  

However I don't think it really applies to this case of ignore lists: it
may mean some files were ignored-but-added when they previously weren't,
or vice versa.  You can still check out the revision, modify the files
and make a new commit.  The only difference as far as I can see is that
if you do a build in that directory then some build products may be
unknown rather than ignored; or conversely some newly added files will
be ignored when they shouldn't be.  So at that point you'd have to fix
up the ignore list, but that seems reasonable because you're now
starting to do new work.

I suppose we could have some marker of how the things are to be
interpreted: old-style globs, new globs, regexps, etc.  But that might
be overkill for now.

-- 
Martin