color: set initial default value for 'colormode' to None
This should not introduce any behavior changes when using the color extension.
In practive, the colormode will be setup at early at run time to the proper
value (from config and environment).
We do this change as this gets us closer of a state were we can have all the
mechanisms associated to color in core with the feature disabled by default.
color: minor reversal of two conditional clause for clarity
Another minor cleanup while reading the code. The two branches of the conditional
have similar complexity so we go for the order that give us the simplest
condition (we drop the negation).
color: merge two identical 'for' loops
The previous changeset made it clear that we are iterating twice on the same
items. We gather the two loops into a single one.
color: minor simplification of some terminfo setup code
No logic change is introduced. The previous code were using a 'dict.update' with
a complex generator. That was a bit confusing to read and not so compact.
Instead we now use an explicit loop and conditional for the sake of clarity.
This also allow for more simplification coming in the next changeset.
color: make a test for curse availability explicite
We won't use terminfo when curse failed to load. Before this change, we were
doing an indirect test, relying on the fact some variable ('_terminfo_params')
would be empty if curses failed to load. We update the code to be more explicit
and directly checks if we managed to load the curse module.
color: move 'win32' declaration to the core module
This is another part of moving color implementation into core. before we can
move the advance logic, we need to move the basic definition and building
bricks. This is one more step on that road.
smartset: preserve istopo for baseset operations
This is a follow-up of "smartset: use native set operations as fast paths".
It's more correct to just preserve the "istopo" information for "&" and "-"
operations, like what filteredset does.
record: update help to describe ui.interface
hg help record was not accurate if using another interface than the text one
ui: replace obsolete default-push with default:pushurl (
issue5485)
Default-push has been deprecated in favour of default:pushurl. But "hg clone" still
inserts this in every hgrc file it creates. This patch updates the message by replacing
default-push with default:pushurl and also makes the necessary changes to test files.
worker: ignore meaningless exit status indication returned by os.waitpid()
Before this patch, worker implementation assumes that os.waitpid()
with os.WNOHANG returns '(0, 0)' for still running child process. This
is explicitly specified as below in Python API document.
os.WNOHANG
The option for waitpid() to return immediately if no child
process status is available immediately. The function returns
(0, 0) in this case.
On the other hand, POSIX specification doesn't define the "stat_loc"
value returned by waitpid() with WNOHANG for such child process.
http://pubs.opengroup.org/onlinepubs/
9699919799/functions/waitpid.html
CPython implementation for os.waitpid() on POSIX doesn't take any care
of this gap, and this may cause unexpected "exit status indication"
even on POSIX conformance platform.
For example, os.waitpid() with os.WNOHANG returns non-zero "exit
status indication" on FreeBSD. This implies os.kill() with own pid or
sys.exit() with non-zero exit code, even if no child process fails.
To ignore meaningless exit status indication returned by os.waitpid(),
this patch skips subsequent steps forcibly, if os.waitpid() returns 0
as pid.
This patch also arranges examination of 'p' value for readability.
FYI, there are some issues below about this behavior reported for
CPython.
https://bugs.python.org/
issue21791
https://bugs.python.org/
issue27808