Summary:
Change the crash header to just a single line without blaming extensions or
Python. This makes the crash log shorter, and easier to read when there are
crashes in run-tests.py diffs.
Remove `ui.supportcontact` since it's no longer used.
Reviewed By: sfilipco
Differential Revision: D14393982
fbshipit-source-id: 3ede8d3d3d8fd5d125944a9a750350d3ce356b14
Summary:
Subrepo is another unloved features that we don't want to support.
Aggressively remove it everywhere, instead of just turning off configs.
I didn't spend much time to split this commit so it's smaller and more friendly
to review. But it seems tests are passing.
Reviewed By: sfilipco
Differential Revision: D14220099
fbshipit-source-id: adc512a047d99cd4bafd0362e3e9b24e71defe13
Summary:
Move the strip extension to core. Rename the command to `hg debugstrip` as it
is not intended for use by users. Users should use `hg hide` instead.
Reviewed By: quark-zju
Differential Revision: D14185822
fbshipit-source-id: ef096488cb94b72a7bb79f5bf153c064e0555b34
Summary:
CommandError happens if there is an unknown command flag, or a required
argument is missing. The old behavior is to print an error message to
stderr, then start the pager with the command help printed to stdout.
There are 2 problems with that approach:
1. When using mosh, a long help text might flush the actual error to out of the
screen. The error message will be missed.
2. When captured in shell scripts, the help text printed to stdout would be
captured, which is almost always undesirable.
The actual motivation of this change is for 2. Zsh themes like bullet-train [1]
uses `hg id -b 2>/dev/null` and we'd like to remove `id -b` support. After that,
the command should not polluate stdout with help text.
[1]: bd88ade263/bullet-train.zsh-theme (L102)
Differential Revision: D14151200
fbshipit-source-id: edd38e91115f96929438379aa2e40edfba560b41
Summary:
`test-patchbomb.t` uses named branches and does not look simple to fix.
We don't use email patches internally, and it's not hard to write scripts
around `hg export`. Therefore drop the extension and its tests.
Reviewed By: singhsrb
Differential Revision: D13978577
fbshipit-source-id: 19867ae68c19c996bfce064eb2234705939db9ea
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Our codebase is already unfriendly to 3rd-party extensions and we will likely
break the compatibility as part of revisising / replacing components in Rust
anyway. So just stop supporting `--config extensions.3rdpartyfoo=`.
Note `--config extensions.3rdpartyfoo=foo.py` still works.
This also makes `ImportError` more meaningful. Previously, when `hgext.foo`
imports `bar` which does not exist, the error is "cannot import foo", while
it should really be "cannot import bar". That is because extensions.py falls
back to import `hgext3rd.foo`, and `foo`. Now extensions.py only tries
`hgext.foo` and will suface the right error.
Reviewed By: DurhamG
Differential Revision: D13440400
fbshipit-source-id: c659f6d05abbc0d09f2811f36c0dc31e49491f19
Summary:
Remove extensions that are not used in prodution. These extensions are also
unlikely to be used in the future.
Reviewed By: ikostia
Differential Revision: D10473370
fbshipit-source-id: a936e30acd3ec4370434c583447942c6ee8d9b13
Summary:
Replace the default help for Mercurial with a curated list of interesting
commands, categorized by their use case.
Reviewed By: phillco
Differential Revision: D10356916
fbshipit-source-id: 65e578a4bfde7b0ad04e7107f4e77d8ea882d78a
Summary:
Parts of the treedirstate implementation were left in the extension. Since
treestate is now in core, and the two are intertwined, treedirstate should be
in core, too.
In doing so:
- Change the garbage collection behaviour to match that of treestate.
- Use the treestate config options for configuring repacking and garbage
collection.
- Make more of the code common.
Reviewed By: quark-zju
Differential Revision: D10258265
fbshipit-source-id: 89e82bc7662a3d1251fa9886751897cfc46cd66a
Summary:
mq is already somehow problematic at D8907646. Without bandwidth supporting
it, let's remove it.
Alternative to mq would be rebase, shelve, unshelve, histedit.
Maintain "--config extensions.mq=" compatibility by marking it builtin so hg4idea
won't break by this change.
Reviewed By: phillco
Differential Revision: D9039741
fbshipit-source-id: a3a1e48a2a982ff8e8b6a6ce659c906a4e2b2b36
Summary:
Similar to chg. Add flags to run tests with watchman. This is mostly moving
features from `fsmonitor-run-tests.py`. The blacklist is converted to
`#require no-fsmonitor`.
Reviewed By: phillco
Differential Revision: D8434518
fbshipit-source-id: a8512cd71c1171e9037f36dbef195f1e6210f27e
Summary:
This adds the ability to specify a config file to be used during the
command. This is useful during clones for letting the clone command use the
given repositories system specified repo-specific hgrc file.
Reviewed By: quark-zju
Differential Revision: D7311576
fbshipit-source-id: a97d8ebada2e0bea27c75a7650df8ede00dc10c6
Summary: Otherwise this test will fill up with default-on tests that will be a pain to filter manually. Plus it's a sensible flag to have.
Differential Revision: D6760553
fbshipit-source-id: 083cb2d8a7cffe28eef812edad2f4c5d997db981
Summary:
...instead of '(untested!)'.
Partly this is necessitated by the `hg debugextensions` call in test-extension.t (post
D6758486). But it also seems like the right thing to do.
Reviewed By: ryanmce
Differential Revision: D6758599
fbshipit-source-id: 3ecfa52b0c9c1a028201d2eda0eaa706d80225c0
# skip-blame because this was mechanically rewritten the following script. I
ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t
ones appear to be, and they run without addition failures on both Windows and
Linux.
import argparse
import os
import re
ap = argparse.ArgumentParser()
ap.add_argument('path', nargs='+')
opts = ap.parse_args()
globre = re.compile(r'^(.*) \(glob\)(.*)$')
for p in opts.path:
tmp = p + '.tmp'
with open(p, 'rb') as src, open(tmp, 'wb') as dst:
for line in src:
m = globre.match(line)
if not m or '$LOCALIP' in line or '*' in line:
dst.write(line)
continue
if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'):
dst.write(line)
continue
dst.write(m.group(1) + m.group(2) + '\n')
os.unlink(p)
os.rename(tmp, p)
I have spent a lot of time debugging extensions that failed to load
because we don't include a traceback and I didn't realize I could get
traceback for the extension failure with --traceback. Let's just turn
them on by default, since it should be rare that the user sees these
tracebacks anyway (and if they do, it's not so bad if the extra
traceback pushes them a little harder to report the problem).
Since we already had a test case with --traceback and one without, I
just removed the one with the flag.
Differential Revision: https://phab.mercurial-scm.org/D1164
A mercurial.bdiff module has existed at some point and when I have
built at an old version, some .pyc file or something seems to stick
around and test-extension.t fails. Let's remove the reference to bdiff
and simplify the test.
Differential Revision: https://phab.mercurial-scm.org/D1162
This test fails when run with chg. This commit just makes the test chg
aware by fixing the output of some of the tests.
Test Plan:
Ran the test 'test-extension.t' with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1160
If the default value of an option is a unicode string (something
than happen easily when using a 'from __future__ import unicode_literals'),
any value passed on the command line will be ignored because the fancyopts
module only checks for byte strings and not unicode strings.
Changing fancyopts behavior is easy but would make assumptions on how
the python3 port should be done, which is outside the scope of this patch.
The chosen approach is to stop an extension from being loaded when a unicode
default value is detected, with a hint for the developer.
The test case depends on the failure happening not at import time, but
at uisetup() time, so it doesn't make sense when demandimport is
disabled.
There was already a section for testing demandimport stuff, so I moved
it inside that existing section. As part of the move, I enabled the
extension using '--config' so subsequent tests don't get the bad
extension enabled.
Differential Revision: https://phab.mercurial-scm.org/D526
In general, the attribute of the same name is overwritten by executing an
import statement.
import a.b
print(a.b.c) # 'c' of a/b/__init__.py
from a.b.c import d
print(a.b.c) # a/b/c.py
However, this appears not true for the scenario described in the test case,
and surprisingly, "from a.b.c import d" works even if "a.b.c" is not a module.
This patch works around the problem by taking the right module from sys.modules
if available.
These are some simple cases. More to come in a future change.
Reviewers: krbullock
Reviewed By: krbullock
Differential Revision: https://phab.mercurial-scm.org/D4
Extensions can have a 'configtable' mapping and use
'registrar.configitem(table)' to retrieve the registration function.
This behave in the same way as the other way for extensions to register new
items (commands, colors, etc).
Before this patch, functions defined in extensions are registered via
extra loaders only in _dispatch(). Therefore, loading extensions in
other code paths like below omits registration of functions.
- WSGI service
- operation across repositories (e.g. subrepo)
- test-duplicateoptions.py, using extensions.loadall() directly
To register functions always at loading new extension, this patch
moves implementation for extra loading from dispatch._dispatch() to
extensions.loadall().
AFAIK, only commands module causes cyclic dependency between
extensions module, but this patch imports all related modules just
before extra loading in loadall(), in order to centralize them.
This patch makes extensions.py depend on many other modules, even
though extensions.py itself doesn't. It should be avoided if possible,
but I don't have any better idea. Some other places like below aren't
reasonable for extra loading, IMHO.
- specific function in newly added module:
existing callers of extensions.loadall() should invoke it, too
- hg.repository() or so:
no-repo commands aren't covered by this.
BTW, this patch removes _loaded.add(name) on relocation, because
dispatch._loaded is used only for extraloaders (for similar reason,
"exts" variable is removed, too).
The previous code was trying to load the extension from /tmp/hgtests.xxx/...,
but the actual path for tests is C:\Users\...\Temp\hgtests.xxx\... I assume
that the former is an MSYS path that maps somewhere under C:\MinGW.
I intend to fix this, but will do the fix as a separate change to make
the behavior change obvious. This was inspired by some users having
the patience diff extension, which broke when we moved bdiff.so so
thoroughly the users can't even run 'hg debuginstall'.
cmdutil.command wasn't a member of the registrar framework only for a
historical reason. Let's make that happen. This patch keeps cmdutil.command
as an alias for extension compatibility.
This can be used to flag patches by branch or topic automatically. Flags
optionally given by --flag option are exported as {flags} template keyword,
so you can add --flag V2.
Now that the feature no longer lives in the extension, we document it in the
help of the core config. This include the new 'ui.color' option introduced in
the previous changesets.
As a result the color extensions can now be deprecated.
This is a documentation patch only; color is still disabled by default.
This new option control whether or not color will be used. It mirror the behavior
of '--color'. I usually avoid adding new option to '[ui]' as the section is
already filled with many option. However, I feel like 'color' is central enough
to deserves a spot in this '[ui]' section.
For now the option is not documented so it is still marked as experimental. Once
it get documented and official, we should be able to deprecate the color
extensions.
There is more cleanup to do before that documentation is written, but we need
this option early to made them. Having that option will allow for more cleanup
of the initialisation process and proper separation between color
configuration.
If we want to be able to move the initialisation in core, we need core to be
aware of that '--color' flag at all time. So we now have the definition in core. That flag
is currently unprocessed without the extensions (will be fixed soon). In
addition the default value for this flag in core is 'never'. Enabling the
extensions change that default value to 'auto'.
