Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 May 2017 22:36:14 -0700] rev 32501
match: split up main matcher into patternmatcher and includematcher
At this point the includematcher is an exact copy of the main matcher
class. We will specialize and simplify both classes in the following
patches. This initial unmodified copy is just to make the differences
clearer. We also rename the main matcher to "patternmatcher" for
consistency.
I may eventually merge this new includematcher back into the main
matcher, but I think doing it this way makes the intermediate steps
clearer regardless.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 May 2017 23:39:39 -0700] rev 32500
match: remove support for exact matching from main matcher class
Exact matching is now handled by the exactmatcher class.
We can safely remove _files from the __repr__() implementation,
because even though the field is set, the patternspat field is enough
for the representation to be unambiguous (which was not the case when
the matcher could handle exact matches).
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 May 2017 09:26:15 -0700] rev 32499
match: handle exact matching using new exactmatcher
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 16:33:33 -0700] rev 32498
merge: use intersectmatchers() in "m2-vs-ma optimization"
It doesn't seem like this can actually happen, but seems like cleaner
anyway.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 12 May 2017 23:12:05 -0700] rev 32497
match: handle includes using new intersectionmatcher
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 May 2017 14:32:56 -0700] rev 32496
match: move entire uipath() implementation to basematcher
Even though most matchers will always want to use the relative path in
uipath(), when we add support for intersecting matcher, we will want
to control which form to use for any kind of matcher without knowing
the type (see next patch), so we need the implementation on the base
class.
Also rename the attribute from "pathrestricted" to "relativeuipath"
since there actually are cases where we match everything but still use
relative paths (like when the user runs "hg files .." from inside
mercurial/).