[PATCH 4 of 4] ignore: use 'include:' rules instead of custom syntax

[Matt Mackall]

On Tue, 2015-05-19 at 17:21 -0500, Pierre-Yves David wrote:
> 
> On 05/19/2015 04:33 PM, Durham Goode wrote:
> >
> >
> > On 5/19/15, 2:31 PM, "Matt Mackall" <mpm at selenic.com> wrote:
> >
> >> On Mon, 2015-05-18 at 17:23 -0700, Durham Goode wrote:
> >>> # HG changeset patch
> >>> # User Durham Goode <durham at fb.com>
> >>> # Date 1431817582 25200
> >>> #      Sat May 16 16:06:22 2015 -0700
> >>> # Node ID dab388963ec2fbffea8cc7d929ad0a45defeafd7
> >>> # Parent  b7160d16c7b38d38236bbfb2ec075909e361f515
> >>> ignore: use 'include:' rules instead of custom syntax
> >>>
> >>> Now that the matcher supports 'include:' rules, let's change the
> >>> dirstate.ignore
> >>> creation to just create a matcher with a bunch of includes. This allows
> >>> us to
> >>> completely delete ignore.py.
> >>>
> >>> I moved some of the syntax documentation over to readpatternfile in
> >>> match.py so
> >>> we don't lose it.
> >>
> >> Thanks, these are queued for default. Can I get you to take a look at
> >> help/patterns.txt? Also, do you still intend to add a relinclude?
> >
> > Yes, the relinclude series is ready (only 3 patches) and will be sent once
> > I see the include stuff pushed.  I'll do a pass over patterns.txt too.
> 
> I think we are getting the name backward here.
> 
> On the command line pattern, we have glob ≠ relglob. But in the ignore 
> file we have glob = relglob. On similar topic 're' ≠ 'relre' on the 
> command line but 're' = 'relre:' in .hgignore
> 
> I think the default case for include is going to be 'relinclude:' and I 
> do not see much usage for 'include:' on the command line.

Yeah, I'd forgotten the weirdness here. So after a bit of poking at the
matcher code to refresh my memory, I see the behavior is:

$ hg st re:p
? p-at-the-start

$ hg st relre:p
? p-at-the-start
? or-anywhere/in-the-path

That is: the "rel" version matches anywhere while the non-rel ones are
anchored to the repo root. Same for globs and -I and -X. That's the
command line.

However, for historical/convenience reasons, .hgignore (and by
extension, your include file reader) automatically promote re->relre and
glob->relglob via the syntaxes dict. 

So technically, if we want "relinclude" to mean "the patterns here match
anywhere" as they do for other rels.. that's what include: does in this
patch. So it should arguably be spelled "relinclude:" on the command
line but remain "include:" in .hgignore file.

So that's easy to fix. But I think you're planning for your next set of
patches isn't a perfect match for the current un-rel kinds because
they're not anchored to the repo root. Instead, I think the intent is to
make them ALSO relative.. but only match inside the subdirectory that
the include file is in, right? Perhaps that should be "subinclude".

In fact, I think that means we conceptually have four types of include
files we might want to implement:

1. root-anchored (what ought to be include: on the command line)
2. relative (this patch)
3. relative, but subdirectory-restricted (what I think your goal is)
4. subdirectory-anchored (for theoretical completeness)

I actually don't know if we care about (1). In fact, we probably want
include:ignore-patterns to do (2) in both cmdline and recursive
contexts. And we we probably don't care about (4)

So, I guess the gist of what I'm saying is.. at the very least, we
shouldn't actually call (3) "relinclude" because it doesn't match our
existing usage of "rel" in this area, and I was misremembering what it
meant when we discussed it earlier.

-- 
Mathematics is the supreme nostalgia of our time.