phabricator: assign commands to help categories
`phabsend` and `phabupdate` seem pretty close to `email`. `phabread` is a
little less close, but can be trivially used to actually import patches.
largefiles: eliminate an unnecessary import of configitems
Thanks to Yuya for pointing this out.
exthelper: add some examples for using registrar aliases
Maybe it's my general lack of python knowledge, but how to use these would be
way too obscure for me otherwise.
exthelper: reintroduce the ability to register filesets
Same mechanism as revsets earlier in this series. The LFS extension is updated
to provide test coverage.
exthelper: reintroduce the ability to register templates
Same mechanism as revsets earlier in this series. The LFS extension is updated
to provide test coverage.
This also seems to make the test failure around
issue6033 mentioned in
0a7f582f6f1f much less regular on Windows.
extensions: deprecate extsetup without a `ui` argument (API)
9.5 years should be enough time, but there were some tests for the old style
still (which are now updated). Exthelper doesn't fallback to the old API, so
this is for consistency.
.. api::
The extension hook ``extsetup`` without a `ui` argument has been deprecated,
and will be removed in the next version. Add a `ui` argument to avoid the
deprecation warning.
largefiles: port revset registration to exthelper
This tests the merge code that wasn't tested in the previous patch.
exthelper: reintroduce the ability to register revsets
I think this is what Yuya and Boris agreed on.[1] This happens *after* the
extsetup phase now (and after the _aftercallback notifications). But this is
trivial, mergeable between exthelper instances, and doesn't need to have the
extension name supplied when registering.
The test needed updating so that extsetup() takes a `ui` argument, as exthelper
isn't trying to be backward compatible with 1.3.1.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-December/125888.html
largefiles: drop the uisetup module
This is small enough to live in the __init__ module.
branches: add -r option to show branch name(s) of a given rev (
issue5948)
Differential Revision: https://phab.mercurial-scm.org/D5486
progress: avoid ui.configbool() lookup when progress bar is active
Profiling revealed that the ui.configbool('progress', 'debug') during
progress bar updates was consuming a significant amount of overhead.
This commit adds an attribute on progress bar instances that caches
this config option.
The impact on `hg perfprogress` with default options is significant:
before: ! wall 4.641942 comb 4.580000 user 4.210000 sys 0.370000 (best of 3)
after: ! wall 1.948626 comb 1.950000 user 1.950000 sys 0.000000 (best of 5)
After this change, profiling reveals that progress.progbar.progress()
is now consuming ~73% of time.
This change does not improve the execution time if the progress bar
is disabled. We may want a more comprehensive solution for that case,
as the progress bar won't be enabled in a number of scenarios (e.g.
servers and processes not attached to an interactive TTY).
I also think that overhead of ~2.0s for 1M updates is a bit high.
I suspect further refactoring of the progress bar can significantly
reduce overhead. I don't have plans to do this, however.
Differential Revision: https://phab.mercurial-scm.org/D5408
largefiles: port wrapped functions to exthelper
Things get interesting in the commit. I hadn't seen
issue6033 on Windows, and
yet it is now reproducible 100% of the time on Windows 10 with this commit. I
didn't test Linux. (For comparison, after seeing this issue, I tested on the
parent with --loop, and it failed 5 times out of over 1300 tests.)
The strange thing is that largefiles has nothing to do with that test (it's not
even mentioned there). It isn't autoloading run amuck- it occurs even if
largefiles is explicitly disabled, and also if the entry in afterhgrcload() is
commented out. It's also not the import of lfutil- I disabled that by copying
the function into lfs and removing the import, and the problem still occurs.
Experimenting further, it seems that the problem is isolated to 3 entries:
exchange.pushoperation, hg.clone, and cmdutil.revert. If those decorators are
all commented out, the test passes when run in a loop for awhile. (Obviously,
some largefiles tests will fail.) But if any one is commented back in, the test
fails immediately.
I left one method related to wrapping the wire protocol, because it seemed more
natural with the TODO. Also, exthelper doesn't support wrapping functions from
another extension, only commands in another extension. I didn't try to figure
out why rebase is both command wrapped and function wrapped.