Wed, 20 Dec 2017 16:44:35 -0800 journal: use pager
Jun Wu <quark@fb.com> [Wed, 20 Dec 2017 16:44:35 -0800] rev 35462
journal: use pager journal output is long and should use a pager. Differential Revision: https://phab.mercurial-scm.org/D1740
Wed, 20 Dec 2017 11:35:38 -0800 commandserver: unblock SIGCHLD
Jun Wu <quark@fb.com> [Wed, 20 Dec 2017 11:35:38 -0800] rev 35461
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
Wed, 20 Dec 2017 02:13:35 -0800 osutil: add a function to unblock signals
Jun Wu <quark@fb.com> [Wed, 20 Dec 2017 02:13:35 -0800] rev 35460
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
Mon, 18 Dec 2017 21:15:53 +0900 sshpeer: move docstring to top
Yuya Nishihara <yuya@tcha.org> [Mon, 18 Dec 2017 21:15:53 +0900] rev 35459
sshpeer: move docstring to top Also makes it use double quotes consistently.
Tue, 19 Dec 2017 21:41:39 +0900 log: make "slowpath" condition slightly more readable
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Dec 2017 21:41:39 +0900] rev 35458
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()
Mon, 18 Dec 2017 11:23:51 -0800 completion: add support for new "amend" command
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Dec 2017 11:23:51 -0800] rev 35457
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
Mon, 18 Dec 2017 09:58:04 -0800 completion: don't suggest clean files to revert
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 Dec 2017 09:58:04 -0800] rev 35456
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip