On 11/01/2016 01:50 PM, Yuya Nishihara wrote:
On Mon, 31 Oct 2016 21:47:35 -0400, Augie Fackler wrote:
On Oct 28, 2016, at 4:40 AM, Pierre-Yves David <pierre-yves.da...@ens-lyon.org>
wrote:
On 10/25/2016 09:41 AM, Rodrigo Damazio Bovendorp via Mercurial-devel wrote:
# HG changeset patch
# User Rodrigo Damazio Bovendorp <rdama...@google.com>
# Date 1475944120 25200
# Sat Oct 08 09:28:40 2016 -0700
# Node ID e8454de81600e092f05aa22ecbac32925b70d074
# Parent 260af19891f2bed679a662be07d1379bb8207592
match: adding support for repository-root-based globs
The broader plan is to add explicit base directories for all patterns:
============ ======== ======= ===========
pattern type root-ed cwd-ed any-of-path
============ ======== ======= ===========
wildcard rootglob cwdglob anyglob
regexp rootre cwdre anyre
raw string rootpath cwdpath anypath
============ ======== ======= ===========
(table by foozy)
The subject seems complicated enough that creating a Plan page seems relevant.
This would help other people to follow what the problem space.
https://www.mercurial-scm.org/wiki/WriteANewFeaturePlan
I’m not sure if it needs a plan page. It strikes me as believable (perhaps even
likely?) that rootglob will be the only part of this implemented for a long
time, perhaps ever. (Having the whole table makes good sense to me though,
because now we’ve though through the future in case it ever comes.)
If I'm counting correctly, this is at least the third time matcher
specification is touched in the history of the project. This instance
have already created multiple email threads with interesting data
"hidden" into them.
I think a plan page is important to give clear picture of the situation
and the proposed solution in a single place. This would help increased
the number of eyes on this topic that history have proved complex.
Especially give how often this topic came up I think it important to
make sure we actually map the problem space and nail the issue once and
for all. I'm a bit concerned we could be taking the minimal step to
snipe a specific requirement here without actually moving toward a real
closure providing a simplified solution that fit all all users.
Regarding how far we'll go in that plan, I hope that at least
"rootre:/rootpath:" will be implement for feature parity with glob.
I'm starting by adding rootglob.
One important characteristic and difference from the older glob types is
that * will never match recursively, even when the glob is used as an include
pattern.
This seems a bit strange to me. Given that the current glob matcher is already
not recursive, why don't we work on an alternative non recursive -I flag
instead?
That means we’ll have a new flag that alters the behavior of existing matchers
in subtle ways. It also requires cooperation from every command that we want to
add new globbing features to, including extensions, whereas if we can add a
couple of new atoms (as outlined in the proposal from foozy) we get consistent
behavior across all matchers.
Command using -I/-X option usually just add the 'walkopts' list to their
option and then pass their 'opts' dict to 'scmutil.match(…)'. So
improving the command flag situation in a unified way does not seems too
scary.
My main concern here is that the vast majority of user will still use
the basic glob we expose without any prefix. If the most common matcher
behave "differently" than all the others, that will get confusing.
That said, the exact state of all existing matchers behavior is getting
fuzzier in my head as the discussion progress. This is one of the reason
I would like to see the current situation and the Foozy plan summarized
into a plan page.
A good way to test¹ design is "how embarrassing is it to explain to new
user" (that is correlated to the simplicity of the design). The recent
discussion and confusion around matcher show that we are not great for
the moment.
It’s a mistake that existing matchers have a recursive * behavior with
--include, but it’s too late to change that. As such, I’d much rather have this
proposal as currently stated.
Given the current globsuffix thing is just for backward compatibility, new
rootglob prefix makes sense to me. Fileset, which is relatively new, behaves
in that way.
On one hand, this extra bits from Yuya increase my wish for a nice
summary of the current situation + objective. On the other hand there it
start to have enough core people who seems to know what they are doing
on this topic to let them work together on this.
So I wish there was a plan page but if none of Foozy, Yuya or Augie
think it is necessary, just go ahead.
% hg files -I 'set:contrib/docker/*'
contrib/docker/centos5
contrib/docker/centos6
contrib/docker/centos7
contrib/docker/debian-jessie
contrib/docker/fedora20
contrib/docker/fedora21
contrib/docker/ubuntu.template
% hg files -I 'contrib/docker/*'
contrib/docker/apache-server/Dockerfile
contrib/docker/apache-server/README.rst
contrib/docker/apache-server/entrypoint.sh
contrib/docker/apache-server/hgwebconfig
contrib/docker/apache-server/vhost.conf
contrib/docker/centos5
contrib/docker/centos6
contrib/docker/centos7
contrib/docker/debian-jessie
contrib/docker/fedora20
contrib/docker/fedora21
contrib/docker/ubuntu.template
Cheers,
--
Pierre-Yves David
[1] I got it from Durham.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
