commandserver: unblock SIGCHLD
This enables the SIGCHLD handler to work properly if some buggy program
started chg server with SIGCHLD blocked.
A test of this probably requires C code, but we don't have such kind of
tests already. Since this is a simple and clear fix, I'm leaving it as
"untested" but I did a manual test and there were no longer zombie workers.
Differential Revision: https://phab.mercurial-scm.org/D1737
osutil: add a function to unblock signals
Signals could be blocked by something like:
#include <unistd.h>
#include <signal.h>
int main(int argc, char * const argv[]) {
sigset_t set;
sigfillset(&set);
sigprocmask(SIG_BLOCK, &set, NULL);
execv("/bin/hg", argv);
return 0;
}
One of the problems is if SIGCHLD is blocked, chgserver would not reap
zombie workers since it depends on SIGCHLD handler entirely.
While it's the parent process to blame but it seems a good idea to just
unblock the signal from hg. FWIW git does that for SIGPIPE already [1].
Unfortunately Python 2 does not reset or provide APIs to change signal
masks. Therefore let's add one in osutil. Note: Python 3.3 introduced
`signal.pthread_sigmask` which solves the problem.
`sigprocmask` is part of POSIX [2] so there is no feature testing in
`setup.py`.
[1]: https://github.com/git/git/commit/
7559a1be8a0afb10df41d25e4cf4c5285a5faef1
[2]: http://pubs.opengroup.org/onlinepubs/7908799/xsh/sigprocmask.html
Differential Revision: https://phab.mercurial-scm.org/D1736
log: make "slowpath" condition slightly more readable
Before
8e0e334bad42 and
6c76c42a5893, the condition was "anypats() or
(files() and --removed)". This can be read as "<match is actually slow>
or <walk files including removed revs>". So "not always()" (i.e. walk
file revs) seems more appropriate here.
The logic should be unchanged:
not anypats() => always() or isexact() or prefix()
isexact() => not always()
prefix() => not always()
completion: add support for new "amend" command
The command is now shipped with Mercurial, but completion should be
helpful (and accurate) for users of the amend command shipped with the
evolve extension too.
Differential Revision: https://phab.mercurial-scm.org/D1716
completion: don't suggest clean files to revert
It looks like we used to suggest only modified, added, removed and
deleted files to revert until
a821ec835223 (completion: selectively
use debugpathcomplete in bash_completion, 2013-03-21). The reasoning
in that commit was that getting the status was too slow and the
replacement (debugpathcomplete) seems to make sense for the other two
commands (remove and forget), but I'm not sure it was intentional to
change the behavior of completion for revert. Note that "add" and
"diff" already use status-based completion.
Differential Revision: https://phab.mercurial-scm.org/D1715
split: new extension to split changesets
This diff introduces an experimental split extension to split changesets.
The implementation is largely inspired by Laurent Charignon's implementation
for mutable-history (changeset
9603aa1ecdfd54b0d86e262318a72e0a2ffeb6cc [1])
This version contains various improvements:
- Rebase by default.
This is more friendly for new users. Split won't lead to merge conflicts
so a rebase won't give the user more trouble.
This has been on by default at Facebook for months now and seems to be a
good UX improvement.
The rebase skips obsoleted or orphaned changesets, which can avoid
issues like allowdivergence, merge conflicts, etc. This is more flexible
because the user can decide what to do next (see the last test case in
test-split.t)
- Remove "Done split? [y/n]" prompt.
That could be detected by checking `repo.status()` instead.
- Works with obsstore disabled.
Without obsstore, split uses strip to clean up old nodes, and it can
even handle split a non-head changeset with "allowunstable" disabled,
since it runs a rebase to solve the "unstable" issue in a same
transaction.
- More friendly editor text.
Put what has been already split into the editor text so users won't lost
track about where they are.
[1]: https://bitbucket.org/marmoute/mutable-history/commits/
9603aa1ecdfd54b
Differential Revision: https://phab.mercurial-scm.org/D1082