pager: avoid shell=True on subprocess.Popen for better errors (
issue5491)
man(1) behaves as poorly as Mercurial without this change. This cribs
from git's run-command[0], which has a list of characters that imply a
string that needs to be run using 'sh -c'. If none of those characters
are present in the command string, we can use shell=False mode on
subprocess and get significantly better error messages (see the test)
when the pager process is invalid. With a complicated pager command
(that contains one of the unsafe characters), we behave as we do today
(which is no worse than git manages.)
I briefly tried tapdancing in a thread to catch early pager exits, but
it's just too perilous: you get races between fd duping operations and
a bad pager exiting, and it's too hard to differentiate between a
slow-bad-pager result and a fast-human-quit-pager-early result.
I've observed some weird variation in exit code handling in the "bad
experience" case in test-pager.t: on my Mac hg predictably exits
nonzero, but on Linux hg always exits zero in that case. For now,
we'll work around it with || true. :(
0: https://github.com/git/git/blob/
cddbda4bc87b9d2c985b6749b1cf026b15e2d3e7/run-command.c#L201
py3: add __bool__ to every class defining __nonzero__
__nonzero__ was renamed to __bool__ in Python 3. This patch simply
aliases __bool__ to __nonzero__ for every class implementing
__nonzero__.
merge: also allow 'e' action with experimental.updatecheck=noconflict
With experimental.updatecheck=noconflict set, if one checks out
f3398f1f70a0 (tests: add execute bit and fix shbang line, 2015-12-22)
and then try to check out its parent, hg will complain about
conflicting changes, even though the working directory is clean. We
need to also allow the 'e' action in merge.py. The 'e' action is used
when moving to a commit where the only change to the file is to its
executable flag, so it's just an optimized 'g' action.
Doesn't seem to be worth writing a test for, since the existing setup
in test-update-branches.t does not set any flags.
exchange: use v2 bundles for modern compression engines (
issue5506)
Previously, `hg bundle zstd` on a non-generaldelta repo would
attempt to use a v1 bundle. This would fail because zstd is not
supported on v1 bundles.
This patch changes the behavior to automatically use a v2 bundle
when the user explicitly requests a bundlespec that is a compression
engine not supported on v1. If the bundlespec is <engine>-v1, it is
still explicitly rejected because that request cannot be fulfilled.