File Name Patterns Plan

[Pierre-Yves David]

Recently, Foozy created a Plan page for the matcher issues:

https://www.mercurial-scm.org/wiki/FileNamePatternsPlan

It is a good start but there is a couple of elements that are
missing or still a bit fuzzy to me.


1) Default matcher:

   What is the default pattern mode ?

   When one do `hg files FOO` how is FOO processed. It seems like to be
   'relpath:'. Double checking this would be useful and mentioning it
   on the page is important.

2) Difference in command behavior:

   There seems to be some commands behaving differently than other,
   notably `hg locates` have some strange kind of
   raw-non-recursive-any-rooted matching by default. It seems to go back to
   'relpath:' when using -I

   I wonder if there is other commands like this. It might be useful to
   search for the default matcher on a command/flag basis.

3) Recursion behavior,

    There is some data about this in the page, but I think we need more
    formal representation to have a clear view of the situation.

    The existing 'path:' and 'relpath:' are recursive in all cases,
    while 'glob:' and 're:' variants are only recursive with -I/-E.
    This is a key point because as far as I understand fixing this is a
    core goal of the current plan.

    However, Foozy point out that using 'set:' with -I disable the
    automatic recursion for 're' and 'glob', but not for 'path', so we
    have more "variants" here.

    (bonus point: Rodrigo use case can we fulfilled by adding 'set:' to
    his selector.)

    I also wonder if there is other variants than "pattern", "-I" and
    "-I + set:".

    Having a table with 'pattern-type / usage' listing the recursive
    case would probably be a good start.

4) Reading from file,

   Foozy mention the pattern name in some file (hgignore) does not
   match pattern name on the command line.

   I think it would be useful to be a bit more formal here. What kind
   of file do we read pattern from? Do we have difference from 1 file
   to another? what are the translation (and default), etc.

5) Pattern-type table

   Foozy made many table explaining how variants are covered by
   pattern type. Having a pattern centric summary will be useful.

   Proposal for columns:

   * pattern type;
   * from cli or file;
   * matching mode (raw, glob, or re),
   * rooting (root, cwd or any),
   * recursive when used as Pattern
   * recursive when used with -I

   Having the same table for the proposed keyword would help to
   understand inconsistency and similarity with

6) file:/dir:

   I'm a bit confused here because Mercurial does not really track/work
   on directories. What is is benefit of 'dir:' ? 'dir:' seems very
   similar to 'path' am I missing something important?

   As I understand 'file:' could be useful for the non-recursive
   part if we want to cover every single cases. Am I right?

7) compatibility conclusion

   Getting a whole new set of matcher is a big step that have a
   significant confusion step, we have to get it right

   We cannot change the default behavior (raw string) and this is what
   people will find the most. So we have to be careful about
   inconsistency here because we cannot change the behavior of this
   current default. For example it is probably better that all the new
   matcher very consistent with each other and that the behavior
   mismatch between raw and the new official one is simple to grasp.

   In the same way, I do not think we'll be able to alias the old
   pattern-type to the new-ones. Because we cannot fix recursion
   behavior of the old ones.
   There will be online material with the old one and we won't be able
   to fix them. This is a lesser issue but we should probably keep it
   in mind. (Without any serious backing I expect that pattern for
   hgignore are probably the most documented online).

Cheers,

-- 
Pierre-Yves David