phabricator: register config settings
I didn't bother registering the deprecated phabricator.auth.*, and I'm not sure
if the two flagged as 'developer config' should be moved to [devel] (or why
there's a distinction between `repophid` and `callsign`).
filemerge: support specifying a python function to custom merge-tools
Eliminates the need to specify a python executable, which may not exist on
system. Additionally launching script inprocess aids portability on systems
that can't execute python via the shell.
Example usage "merge-tools.myTool.executable=python:c:\myTool.py:mergefn"
where myTool.py contains a function:
"def mergefn(ui, repo, args, **kwargs):"
where args is list of args passed to merge tool.
(by default, expanded: $local $base $other)
Invoking the specified python function was done by exposing and invoking
(hook._pythonhook -> hook.pythonhook)
help: correct signature of separate() template function
Without the dots, it looked as if separate() would take a list of arguments.
hgweb: do not try to replace signal handlers while locking
According to the issue 5889, mod_wsgi issues a warning on signal.signal()
call, and we wouldn't want to see it in error log. The problem addressed
by
d77c3b023393 could potentially occur in web session, but that would be
less likely than in user processes.
lock: add internal config to not replace signal handlers while locking
signal.signal() is blocked in some WSGI environments, and a horrible warning
is sent to the server log. So we need a way to disable it, and I think
abusing ui.config is the simplest workaround.
i18n-pt_BR: synchronized with
32a75a8a5b0f
i18n-ja: synchronized with
32a75a8a5b0f
httppeer: declare 'dbg' at the function level
As we just saw in the previous changeset, having the variable defined into a
branch creates bug. This is a cheap to move it at the function level.