As I've said on earlier patches, I'm hoping to use more composition of
simpler matchers instead of the single complex matcher we currently
have. This extracts a first new matcher that composes two other
matchers. It matches if the first matcher matches but the second does
not. As such, we can use it for excludes, which this patch also
does. We'll remove the now-unncessary code for excludes in the next
patch.
d46a7814be5f refactored util.parsedate in order to raise ValueError instead
of Abort for using with ui.configwith. It causes several problems, putting
arbitrary bytes in ValueError can cause issues with Python 3. Moreover, we
added a function to convert ValueError exceptions back to Abort.
A better approach would be to make parsedate raises ParseError, removing
the convert function and update configwith to also catch ParseError.
The side-effect is that error message when giving an invalid date in CLI
change from:
abort: invalid date: 'foo bar'
to:
hg: parse error: invalid date: 'foo bar'
I'm not sure if it's an acceptable change, I found personally the error
message more clear but more verbose too.
I'm hoping to rewrite the matcher so excludes are handled by
composition of one matcher with another matcher where the second
matcher has only includes. For that to work, we need to make
visitdir() to return 'all' for directory 'foo' for a '-I foo' matcher.
This makes the subdirmatcher not depend on the main matcher, giving us
more freedom to modify that (specifically, it will lose it _always
field in a while).
We will soon start splitting up the current matcher class into more
specialized classes, so we'll want a base class for all the things
that don't vary much between different matchers.
The function use the length of the repository, something affected by filtering.
It seems better to use the unfiltered length here.
Credit for finding this goes to Durham Goode.
I just burned myself on this today because I left out the -r in my `hg
bookmark` command, which then left me confused because I didn't notice
the bookmark I created in the wrong place that was silently shadowing
the revision I was trying to check out. Let's warn the user.
This patch only enforces the check on bookmark names 4 characters long
or longer. We can tweak that if we'd like, I selected that since
that's the fewest characters shortest will use in the templater
output.
A previous version of this patch rejected such bookmarks. It was
proposed during review (and I agree) that the behavior change for a
bookmark named "cafe" or similar as history accumulated was a little
too weird, but that the warning definitely has merit.
d46a7814be5f introduced util._parsedate with the aim to be used in
ui.configdate but ui.configdate was using util.parsedate instead. It have the
impact of raising an AbortError in case of an invalid date instead of a
ConfigError exception. Fix ui.configdate to use the right function and add a
test for invalid dates.
Thanks to Yuya for the catch!
When we try to run, 'hg debugrevspec 'branch(wdir())'', it throws an index error
and blows up. Lets raise the WdirUnsupported if wdir() is passed so that we can
catch that later.
For wdir(), we now raises an exception which will be raised when wdir() will be
passed, so catching that exception is better checking for wdir() using if-else.
This simplifies things a little by making the actual act of turning a
revision into patch data a single function. After this, adding
formatter support to `hg export` should be much simpler.
Recent mailing list discussion made me realised we could clarify these. We make
the function "public" to encourage extensions to wrap it and we use a more
explicit name that mirror "hideablerevs".
459366b580cf makes profiler start early without loading extensions. That
makes it impossible for an extension to add customized profilers.
This patch adds a special case: if a profiler is not found but an extension
with the same name could be loaded, load that extension first, and expect it
to have a "profile" contextmanager method. This allows customized profilers
and extension setup time is still profiled.
Exact matchers are only created internally (as opposed to from user
input) based on a set of files that the caller collected before, so
they should always match the list exactly (i.e. case-sensitively).
Also use the default-date when creating obsmarkers. Currently they are created
with the current date and without any option to force their value.
To test the feature, we remove some of the many 'glob' used to match obsmarker
date in the tests.
Add a new config field named default-date under the devel section to force all
implicits date to a specific value. If a explicit date is passed, it will
override the default.
This patch only affect changesets. Other usages (blackbox, obsmarkers) are
updated in later patchs.
The test runner is setting a bunch of alias to force the '--date' argument. We
will replace theses aliases in a later patch.
Split most of util.parsedate in util.rawparsedate and make it raises ValueError instead
of error.Abort.
The util.parsedate function is now just a shell function converting ValueError
to error.Abort for existing users.
I need to parse a date from config in a later patch and use util.rawparsedate
with ui.configwith which expect a convert that raises ValueError.
fsmonitor and debugignore currently access matcher fields that I would
consider implementation details, namely patternspat, includepat, and
excludepat. Let' instead implement __repr__() and have the few users
use that instead.
Marked (API) because the fields can now be None.
revlog.parentrevs() is called while evaluating ^ operator in revsets. When wdir
is passed, it raises IndexError. This patch raises WdirUnsupported if wdir is
passed in the function. The error will be caugth in future patches.
This series intents to support wdir() predicate with different operators
like ~, ^.
Currently the storage class don't support wdir(). This exception is introduced
so that it can be raised from places where wdir() is passed and is not
supported and we can catch this where we want to support the predicate.
Also throwing an error at low level and catching at some higher level is better
than using if-else especially for perf.
match() will soon gain more logic and we don't want to duplicate that
in icasefsmatch(), so merge the two functions instead and use a flag
to get case-insensitive behavior.
On case-insensitive file systems, if file A exists and you try to
remove it (or add, etc.) by specifying a different case, you will see
something like this:
$ hg rm a
removing file A
I honestly found this surprising because it seems to me like it was
explicitly listed by the user. Still, there is a comment in the code
describing it, so it is very clearly intentional. The code was added
in d70aa474bd84 (match: add a subclass for dirstate normalizing of the
matched patterns, 2015-04-12).
I'm going to do a lot of refactoring to matchers and the feature
mentioned above is going to get in my way. I'm therefore removing it
for the time being and we can hopefully add it back when I'm done.
matcher._normalize() no longer depends on any of the matcher's state,
and making it static will enable further refactoring. Note that the
subdirmatcher subclass calls _normalize(), so we can't remove it
completely.
