Summary:
When using ui.configoverrides, it was previously just backing up
self._rcfg. It turns out that calling ui.setconfig (which is called as part of
configoverrides) will mark the given config as pinned and potentially
unserializable. If a config is pinned, that means we will never again read a
value into it, so when we open a bundlerepo and attempt to load the repo
specific hgrc into it, any pinned values simply don't get written.
So there are two bugs here:
1. overriding a config should not result in the config key being considered
pinned forever.
2. Cloning a ui should reset the pinned list since we don't actually clone any
of the pinned data into the new ui
Either of these alone would fix our problem with bundlerepos, but both are
necessary for general correctness.
Reviewed By: ikostia
Differential Revision: D15074037
fbshipit-source-id: 37f67f13f1d2975299be97d796b52ec2b97bca24
Summary:
akushner and I both hit an issue where `hg log` hangs for a long time after
exiting the pager by pressing `q`. That was caused by D14528603. Revert it to
fix it.
The root cause is apparently a bug in Python 2 (or C stdlib?):
# a.py
import signal, os
signal.signal(signal.SIGPIPE, signal.SIG_IGN)
out = os.fdopen(1, 'wb', 1)
while True:
out.write(b"a\n")
# shell
python2 a.py | head -n 1
# hangs
Python 3 does not have the issue.
Reviewed By: singhsrb
Differential Revision: D14603974
fbshipit-source-id: 3b4d716133853632e56dfeb59b1858f926a2c146
Summary:
Make it possible to use `ui.metrics.gauge` to collect metrics for a single
command, via the sampling extension.
Differential Revision: D14515775
fbshipit-source-id: e8a53549b00c1bc7b6509a5990a51d955d767d7e
Summary:
SIGPIPE is a weird signal. It is sent to a process that tries to write to a
pipe (or socket) whose other end has been closed. On top of the signal being
sent, the write will also fails with EPIPE, and thus SIGPIPE is sometimes used
to avoid checking the return status of write (!!!) and to gracefully exit.
In Mercurial, the SIGPIPE is used to raise an exception to do exactly this, but
it also appears that the writes to stdout/stderr are already checking the
return value and doing the right thing, hence SIGPIPE is unecessary.
In the case of Mercurial, catching SIGPIPE has another interesting behavior.
The command `hg log -p` has a different behavior once the pager is killed
depending on whether HGPLAIN is set or not. When unset, `stderr` is also
redirected to the pipe, and thus any logs printed after the pipe is closed will
force Mercurial to quit. While this is the expected behavior in most cases,
it is not when the logs are happening during cleanup, as they will effectively
abort the teardown process.
Overall, it's better to just not install a SIGPIPE handler, so let's remove it.
Reviewed By: kulshrax
Differential Revision: D14528603
fbshipit-source-id: f51fb13016cc7b8d622e91c60d4c5286c7b404e5
Summary:
Add a `pager.stderr` config option that when set to false, disables the
redirection of stderr to the pager.
This means progress bars will be rendered, and other information will appear
synchronously, rather than buffered by the pager, but also that Mercurial will
start outputting stderr over the top of any output that the pager produces,
potentially corrupting the pager display.
Reviewed By: simpkins
Differential Revision: D14130965
fbshipit-source-id: eba8e31fdad05c935eae13e1900c5f7e5af7ecbc
Summary:
Move all Rust bindings to a single python extension, `bindings`. This should
improve compilation time and make things simpler.
Reviewed By: quark-zju
Differential Revision: D13923866
fbshipit-source-id: 560592b5a6c0c4f1b836c755ef123666a1059164
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
