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.
The test-xdg.t test uses the system hgrc because it unsets HGRCPATH. If the
system has an extension enabled that doesn't work with the development version
of Mercurial it prints an 'extension failed to load' warning. Let's just hide
that by piping stderr to /dev/null.
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".
This uses the new demandimport implementation for Python 3 introduced in
previous patches.
This doesn't yet enhance performance because it isn't integrated with the
custom source file loader we use on Python 3. We'll integrate the two in
upcoming patches.
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).