Phil Cohen <phillco@fb.com> [Wed, 20 Dec 2017 17:22:16 -0600] rev 35463
filemerge: only raise InMemoryMergeConflictsError when running _xmerge
The old code here was overly broad and would raise in cases when we didn't end
up calling `xmerge` and resolved using an internal tool (such as when
`premerge=True`).
Instead, let's swap out _xmerge if IMM is enabled and have the new tool raise
when called, which is the behavior we want.
Differential Revision: https://phab.mercurial-scm.org/D1739
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
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
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
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.
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()
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
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
Jun Wu <quark@fb.com> [Sat, 24 Jun 2017 23:03:41 -0700] rev 35455
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
Augie Fackler <augie@google.com> [Tue, 19 Dec 2017 16:27:24 -0500] rev 35454
merge with stable
Wojciech Lis <wlis@fb.com> [Mon, 18 Dec 2017 15:18:37 -0800] rev 35453
worker: handle interrupt on windows
After applying suggestions from https://phab.mercurial-scm.org/D1564
to catch all exceptions in the same way I actually broke the handling of
KeyboardInterrupt on windows. The reason is that KeyboardInterrupt doesn't
dervie from Exception, but BaseException:
https://docs.python.org/2/library/exceptions.html starting from python 2.5
Test Plan:
Run hg on windows and ctrl-c during a large update. No random
exceptions from threads surface in the shell. Previously we'd nearly always get
stack traces from some of threads
Run tests ./run-tests.py
[...]
Failed test-convert-svn-encoding.t: output changed
# Ran 622 tests, 41 skipped, 1 failed.
python hash seed:
2962682116
The test failing seems to have nothing to do with the change and fails on base
revision as well
Differential Revision: https://phab.mercurial-scm.org/D1718
Jun Wu <quark@fb.com> [Mon, 18 Dec 2017 14:37:00 -0800] rev 35452
lfs: fix committing deleted files caused by
e0a1b9ee93cd
e0a1b9ee93cd (lfs: add a repo requirement for this extension once an lfs
file is committed) introduced a regression that prevents committing file
deletion. This patch fixes that.
Differential Revision: https://phab.mercurial-scm.org/D1717