Summary:
This removes Python alias handling so the alias handling is done entirely in
Rust.
There are some subtle changes - alias using prefix mathcing to ambiguous
commands will not show other aliases. Hopefully that won't be a big issue.
Users can always avoid prefix matching in alias to solve the issue.
Reviewed By: sfilipco
Differential Revision: D16733270
fbshipit-source-id: 54a4915d49c2b2f6e8664a225a9c0f25e1c38d17
Summary:
Translate alias like `echo = !echo foo` to `echo = debugrunshell '--cmd=echo
foo'`. This enables the Rust shell alias handling code path. The Python
shell alias handling was removed.
The majority part of `test-alias.t` still passes. That includes some "weird"
shell alias features.
This has some test changes, through:
- `$HG_ARGS` is no longer supported. And tests depending on it are changed.
`$@` will be the alternative for most cases.
Practically, our `$HG_ARGS` users seem to come from
https://stackoverflow.com/a/833387, which does not seem to use `$HG_ARGS`
correctly (since `$HG_ARGS` includes the command name).
- Early-parse commands (ex. `hg log -b '--config=alias.log=!echo
howdy'`) no longer works.
- The warning `--repository ignored` now shows up, since `debugrunshell`
is a "no-repo" command.
- Global flags can no longer be used after shell aliases. Supporting them
is a head-ache.
- `circular alias` error message changed because it's now reported by the Rust
code, which does not report all alias names right now.
Reviewed By: sfilipco
Differential Revision: D16733266
fbshipit-source-id: b06bc7f8fc2f1c2701a17407d6a1656e17e4ba55
Summary: When selective pull will be enabled, `hg log` won't be able to show any information about the remote bookmarks that are not in subscriptions for particular user. So we need to hint the user that they may want to explicitly pull the remote bookmark first, if hg log fails to find it.
Reviewed By: quark-zju
Differential Revision: D15516462
fbshipit-source-id: 5be77b0048d8e175a737f76a8e89768f4c837f60
Summary:
Now that all our repos are treemanifest, let's enable the extension by
default in tests. Once we're certain no one needs it in production we'll also
make it the default in core Mercurial.
This diff includes a minor fix in treemanifest to be aware of always-enabled
extensions. It won't matter until we actually add treemanifest to the list of
default enabled extensions, but I caught this while testing things.
Reviewed By: ikostia
Differential Revision: D15030253
fbshipit-source-id: d8361f915928b6ad90665e6ed330c1df5c8d8d86
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:
Update pest to 2.1.0.
This version has a new behaviour for parser error messages: the line feed at
the end of the line is shown in the error output.
Reviewed By: wez
Differential Revision: D13671099
fbshipit-source-id: b8d1142a44a56a0b21b3b72cf027f3f8a30f421e
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:
Switch `ui.load` and `ui.readconfig` to use the Rust config parser.
`ui` now no longer depends on `config.config` or `rcutil`.
Pest's error messages are fancier, thus most test changes.
For the fbsource repo, debugshell shows the new code is 10+x faster:
On laptop:
Before:
In [1]: %timeit m.ui.ui.load()
10 loops, best of 3: 27.8 ms per loop
After:
In [1]: %timeit m.ui.ui.load()
100 loops, best of 3: 1.85 ms per loop
On devserver:
Before:
In [1]: %timeit m.ui.ui.load()
100 loops, best of 3: 16.8 ms per loop
After:
In [1]: %timeit m.ui.ui.load()
1000 loops, best of 3: 1.28 ms per loop
Since `ui._rcfg` is no longer copy-on-write, there is concern about `ui.copy()`
performance. It is faster too (on devserver):
Before:
In [1]: %timeit ui.copy()
1000 loops, best of 3: 198 µs per loop
After:
In [1]: %timeit ui.copy()
10000 loops, best of 3: 157 µs per loop
The old `ui.py` was copied to `legacyui.py` and can replace the new `ui.py` if
a config file exists on the system. This provides a way to switch back to the
old config parser in case of emergency.
Reviewed By: mitrandir77
Differential Revision: D8887375
fbshipit-source-id: 2951ca622c77bf41187ad5c5cab3445cda0dc519
# 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)
Automatic replacement seems better than trying to figure out a check-code rule.
I didn't bother looking to see why the error message and file name is reversed
in the annotate and histedit tests, based on Windows or not.
I originally had this as a list of tuples, conditional on the platform. But
there are a couple of 'No such file or directory' messages emitted by Mercurial
itself, so unconditional is required for stability. There are also several
variants of what I assume is 'connection refused' and 'unknown host' in
test-clone.t and test-clonebundles.t for Docker, FreeBSD jails, etc. Yes, these
are handled by (re) tags, but maybe it would be better to capture those strings
in order to avoid whack-a-mole in future tests. All of this points to using a
dictionary containing one or more strings-to-be-replaced values.
This prepares for replacing old _early*opt() functions. My initial attempt
was to extend options table to support 'repository|repo' syntax. It worked,
but seemed too invasive. So I decided to add an optional argument to
fancyopts() instead.
This also changes the nevernegate dict to be keyed by a canonical_name,
not by an option-name for clarity.
If this feature is enabled, early options are parsed using the global options
table. As the parser stops processing options when non/unknown option is
encountered, it won't mistakenly take an option value as a new early option.
Still "--" can be injected to terminate the parsing (e.g. "hg -R -- log"), I
think it's unlikely to lead to an RCE.
To minimize a risk of this change, new fancyopts.earlygetopt() path is enabled
only when +strictflags is set. Also the strict parser doesn't support '--repo',
a short for '--repository' yet. This limitation will be removed later.
As this feature is backward incompatible, I decided to add a new opt-in
mechanism to HGPLAIN. I'm not pretty sure if this is the right choice, but
I'm thinking of adding +feature/-feature syntax to HGPLAIN. Alternatively,
we could add a new environment variable. Any bikeshedding is welcome.
Note that HGPLAIN=+strictflags doesn't work correctly in chg session since
command arguments are pre-processed in C. This wouldn't be easily fixed.
Before, early options were stripped from args, and because of this, some
kind of parsing errors weren't reported. For example,
$ hg ci -m -Ra file
would execute "hg ci -m file" in repository "a".
This patch fixes the issue by parsing early options again by real getopt-based
parser, and verifying the results. If the early parsing appears wrong, hg just
aborts. The current error message seems not nice, and should be improved, maybe
in V2 or follow-up.
Note that this isn't a security feature because we can still do anything by
using shell aliases.
Perhaps we'll need to restrict the parsing rules of --debugger and --profile,
where this patch will help us know why the --debugger option doesn't work.
I have another series to extend this feature to --config/--cwd/-R, but even
with that, shell aliases can be used to get around the restriction.
When cwd is removed and `hg` is executed, some shells may run `getcwd`
before forking and executing, some may not do it, some may print a
different error message.
The test should be shell-independent so let's just avoid checking the error
message.
Differential Revision: https://phab.mercurial-scm.org/D1282
The test is broken when run with chg because it prints a different
error message when chg is running. This commit fixes the test by special casing
for chg.
Test Plan:
Ran the test 'test-dispatch.t' with and without '--chg' option.
Differential Revision: https://phab.mercurial-scm.org/D1126
With hgdemandimport disabled (chg's case), `import uuid` has an immediate
side effect calling `ctypes.util.find_library` trying to locate the
`libuuid` library. This happens at `import` time before `dispatch.run()`.
The call trace is like:
File "hg/hg", line 54, in <module>
from mercurial import (
File "hg/mercurial/dispatch.py", line 24, in <module>
from . import (
File "hg/mercurial/commands.py", line 23, in <module>
from . import (
File "hg/mercurial/help.py", line 33, in <module>
from .hgweb import (
File "hg/mercurial/hgweb/__init__.py", line 20, in <module>
from . import (
File "hg/mercurial/hgweb/hgweb_mod.py", line 14, in <module>
from .common import (
File "hg/mercurial/hgweb/common.py", line 15, in <module>
import uuid
File "/usr/lib64/python2.7/uuid.py", line 404, in <module>
lib = ctypes.CDLL(ctypes.util.find_library(libname))
The problem is, `ctypes.util.find_library` will execute
`sh -c '/sbin/ldconfig -p 2>/dev/null'` on Python <= 2.7.12. The output of
`sh` may pollute the terminal:
shell-init: error retrieving current directory: getcwd: cannot access
parent directories: No such file or directory
This patch moves `import uuid` so its side-effect can only happen after the
cwd check in `dispatch._getlocal`. Therefore the terminal won't be
polluted by importing `uuid`.
Differential Revision: https://phab.mercurial-scm.org/D1024
The ability to negate any boolean flags itself is great, but I think we are not
ready to expose the help side of it yet.
First, while there exist a handful of such flags whose default value can be
changed (eg: git diff, patchwork confirmation), there is only a few of them. The
users who benefit the most from this change are alias users and large
installation that can deploy extension to change behavior (eg: facebook
tweakdefault). So the majority of user who will be affected by a large change
to command help that is not yet relevant to them. (I expect this to become
relevant when ui.progressive start to exists).
Below is an example of the impact of the new help on 'hg help diff':
-r --rev REV [+] revision
-c --change REV change made by revision
-a --[no-]text treat all files as text
-g --[no-]git use git extended diff format
--[no-]nodates omit dates from diff headers
--[no-]noprefix omit a/ and b/ prefixes from filenames
-p --[no-]show-function show which function each change is in
--[no-]reverse produce a diff that undoes the changes
-w --[no-]ignore-all-space ignore white space when comparing lines
-b --[no-]ignore-space-change ignore changes in the amount of white space
-B --[no-]ignore-blank-lines ignore changes whose lines are all blank
-U --unified NUM number of lines of context to show
--[no-]stat output diffstat-style summary of changes
--root DIR produce diffs relative to subdirectory
-I --include PATTERN [+] include names matching the given patterns
-X --exclude PATTERN [+] exclude names matching the given patterns
-S --[no-]subrepos recurse into subrepositories
Another issue with the current state of help, the default value for the
flag is not conveyed to the user. For example in the 'backout' help, there is
no real distinction between "--[no-]backup" (default to True) and "--[no-]keep"
(default) to False:
--[no-]backup no backups
--[no-]keep do not modify working directory during strip
In addition, I've discussed with Augie Fackler and the last batch of the work on
this have burned him out quite some. Therefore he is not intending to perform
any more work on this topic. Quoting him, he would rather see the help part
backed out than spending more time on it.
I do not think we are ready to expose this to users in 4.0 (freeze in a week),
especially because we cannot expect quick improvement on these aspect as this
topic no longer have an owner. We should be able to reintroduce that change in
the future when someone get back on it and the main issues are solves:
* Introduction of ui.progressive makes it relevant for a majority of user,
* Current default value are efficiently conveyed to the user.
(In addition, the excerpt from diff help show that we still have some issue with
some negative option like '--nodates' so further improvement are probably
welcome there.)
That is, help gets tweaked thus:
global options ([+] can be repeated):
-v --[no-]verbose enable additional output
Other proposals have included:
global options ([+] can be repeated, options marked [?] are boolean flags):
-v --verbose[?] enable additional output
and
global options ([+] can be repeated, options marked [^] are boolean flags):
-v --verbose[^] enable additional output
which avoid the unfortunate visual noise in this patch. In this
version's favor, it's consistent with what I'm used to seeing in man
pages and similar documentation venues.
Mercurial would sometimes exit with:
abort: No such file or directory
where str of the actual OSError exception was the more helpful:
[Errno 2] No such file or directory: ''
The exception will now always show the filename and quote it:
abort: No such file or directory: ''
Example
$ hg clone --jump foo bar
hg clone: option --jump not recognized
hg clone [OPTION]... SOURCE [DEST]
make a copy of an existing repository
options:
-U --noupdate the clone will include an empty working copy (only a
repository)
-u --updaterev REV revision, tag or branch to check out
-r --rev REV [+] include the specified changeset
-b --branch BRANCH [+] clone only the specified branch
--pull use pull protocol to copy metadata
--uncompressed use uncompressed transfer (fast over LAN)
-e --ssh CMD specify ssh command to use
--remotecmd CMD specify hg command to run on the remote side
--insecure do not verify server certificate (ignoring
web.cacerts config)
[+] marked option can be specified multiple times
use "hg help clone" to show the full help text
Motivation for this change
If the user already has specified the command, he probably already knows
the command to some extent. Apparently, he has a problem with the options,
so we show him just the synopsis with the short help and the details about
the options, with a hint on the last line how to get the full help text.
Why is Mercurial better with this change?
Experts who just forgot about the details of an option don't get that
much text thrown at them, while the newbies still get a hint on the last
line how to get the full help text.
