Yuya Nishihara <yuya@tcha.org> [Tue, 19 Jan 2016 22:31:59 +0900] rev 28086
chg: forward job control signals to worker process (
issue5051)
This is necessary to suspend/resume long pulls, interactive curses session,
etc.
The implementation is based on emacsclient, but our version doesn't test if
chg process is foreground or not before propagating SIGCONT. This is because
chg isn't always an interactive session. If we copy the SIGTTIN/SIGTTOU
emulation from emacsclient, non-interactive session can't be moved to a
background job.
$ chg pull
^Z
suspended
$ bg %1
[1] continued
[1] suspended (tty input) # wrong
https://github.com/emacs-mirror/emacs/blob/0e96320/lib-src/emacsclient.c#L1094
Yuya Nishihara <yuya@tcha.org> [Fri, 29 Jan 2016 22:52:16 +0900] rev 28085
chg: verify return value of sigaction() and sigemptyset()
They should never fail, but it couldn't hurt to be a paranoid.
Yuya Nishihara <yuya@tcha.org> [Fri, 29 Jan 2016 22:42:22 +0900] rev 28084
chg: initialize sigaction fields more reliably
It seems calling memset() and sigemptyset() is common pattern to initialize
sigaction. And strictly speaking, sigset_t must be initialized by sigemptyset()
or sigfillset(). I saw git and uwsgi do that way, so let's follow them.
Simon Farnsworth <simonfar@fb.com> [Fri, 12 Feb 2016 06:25:05 -0800] rev 28083
tests: confirm that a badly documented extension doesn't cause a crash
An external extension whose docstring doesn't conform to Mercurial standards
used to cause crashes. Test that we omit such extensions when you do a
keyword search.
Martijn Pieters <mjpieters@fb.com> [Fri, 12 Feb 2016 14:24:48 +0000] rev 28082
bookmarks: avoid creating a nested repository during testing
This helps the test to pass with hgwatchman, which would otherwise need to be
taught about a nested .hg directory. hgwatchman already blacklists
test-nested-repo.t which covers the actual usecase
Tony Tung <ttung@fb.com> [Mon, 08 Feb 2016 15:35:30 -0800] rev 28081
dispatch: strip command line options like config file options
Currently, whitespace in command line --config options are considered
significant while whitespace in config files are not considered
significant. This diff strips the leading and trailing whitespace from
command line config options.
Siddharth Agarwal <sid0@fb.com> [Thu, 11 Feb 2016 22:52:23 -0800] rev 28080
hook: for python hook ImportErrors, add note to run with --traceback
I personally found it completely non-obvious that --traceback prints out stack
traces for failed imports.
Siddharth Agarwal <sid0@fb.com> [Thu, 11 Feb 2016 22:41:20 -0800] rev 28079
hook: fewer parentheses for hook load errors
This matches 'hook failed' warnings.
We're also going to add hints to some of the hook load errors. Without this
change we'd have two pairs of parens for a single error message, which looks
really cluttered.
Siddharth Agarwal <sid0@fb.com> [Thu, 11 Feb 2016 22:02:52 -0800] rev 28078
hook: use sys.exc_info rather than the deprecated equivalents
sys.exc_type etc have been deprecated since Python 1.5.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 11 Feb 2016 23:15:34 +0900] rev 28077
doc: describe full help document hierarchy to create a valid link in HTML
For example, ":hg:`help config.default-push`" creates an invalid link
to "hgrc.5.html#default-push" in HTML, but ":hg:`help
config.paths.default-push`" creates a valid link to
"hgrc.5.html#paths".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 11 Feb 2016 23:15:34 +0900] rev 28076
doc: translate from :hg:`help config.SECTION` to a valid link to hgrc.5.html
Before this patch, ":hg:`help config.SECTION`" in online help text is
translated to a link to "hg.1.html#config.SECTION" in HTML
unintentionally.
This patch translates from :hg:`help config.SECTION` in online help
text to a valid link to "hgrc.5.html#SECTION" in HTML.
This patch ignores element(s) under "SECTION" (e.g. "ITEM" of
":hg:`help config.SECTION.ITEM`"), because there is no way to refer
directly to it in HTML, yet.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 11 Feb 2016 23:15:34 +0900] rev 28075
doc: translate from :hg:`help config` to a valid link to hgrc.5.html
Before this patch, ":hg:`help config`" in online help text is
translated to a link to "hg.1.html#config" in HTML, even though actual
"hg help config" shows not help for "hg config" command but "config"
help topic, and all of current ":hg:`help config`" expects the latter.
This patch translates from ":hg:`help config`" in online help text to
a link to "hgrc.5.html" in HTML as expected.
This patch also allows ":hg:`help -c COMMAND`" style to link
"hg.1.html#COMMAND" for readability.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 11 Feb 2016 23:15:34 +0900] rev 28074
i18n: calculate correct line number in source of messages to be translated
Before this patch, line number in source of the message to be
translated is wrong in hg.pot, if corresponded message is placed after
".. DIRECTIVE::", because number of lines related to such directive
isn't added to variable "delta", which holds number of untranslated
lines in given text.
This patch always adds "2" to "delta", because text block is split
into translation units by "\n\n".
Durham Goode <durham@fb.com> [Wed, 10 Feb 2016 12:39:25 -0800] rev 28073
revsetbenchmark: handle exception case
If the revset being benchmarked has an exception, the handling code was
encountering an error because the exception did not always have an "output"
attribute (I think it's a python 2.7 thing).
Ryan McElroy <rmcelroy@fb.com> [Wed, 10 Feb 2016 09:06:08 -0800] rev 28072
merge: minimize conflicts when common base is not shown (
issue4447)
Previously, two changes that were nearly, but not quite, identical would result
in large merge conflict regions that looked very similar, and were thus very
confusing to users, and lead people used to other source control systems to
claim that "mercurial's merge algorithms suck". In the relatively common case
of a new file being introduced in two branches with very slight modifications,
the old behavior would show the entire file as a conflict, and it would be very
difficult for a user to determine what was going on.
In the past, mercurial attempted to solve this with a "very smart" algorithm
that would find all common lines, but this has significant problems as
described in
2ea6d906cf9b.
Instead, we use a "very dumb" algorithm introduced in the previous patch that
simply matches lines at the periphery of conflict regions. This minimizes most
conflict regions well, though there may still be some degenerate edge cases,
like small modification to the beginning and end of a large file.