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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
