config: rename ui.mergemarkertemplate to command-templates.mergemarker Differential Revision: https://phab.mercurial-scm.org/D9247

config: rename ui.graphnodetemplate to command-templates.graphnode Differential Revision: https://phab.mercurial-scm.org/D9246

config: add a new [command-templates] section for templates defined by hg The existing `[templates]` section lets the user define their own keys and then refer to them on the command line with `-T`. There are many cases where hg wants to use a user-defined template with a given name, such as `ui.logtemplate` and `ui.mergemarkertemplate`. This patch starts moving such configs in a common section by moving `ui.logtemplate` to `command-templates.log` (with an alias from the old name, of course). Differential Revision: https://phab.mercurial-scm.org/D9245

i18n: fix coding tag unsupported by xgettext Running `make update-pot` currently fails with the following error: xgettext: mercurial/metadata.py:1: Unknown encoding "utf8". Proceeding with ASCII instead. xgettext: Non-ASCII string at mercurial/metadata.py:311. Please specify the source encoding through --from-code or through a comment as specified in http://www.python.org/peps/pep-0263.html. Differential Revision: https://phab.mercurial-scm.org/D9260

py3: hggettext `itervalues()` is only available on Python 2. Since this script doesn't currently refer to the main Mercurial modules, and as a result doesn't have easy access to the `pycompat` module, I simply changed it to use `value()` instead. Although this allocates a list on Python 2, I'd consider that acceptable for a utility script; Mercurial doesn't have all _that_ many commands anyway. Differential Revision: https://phab.mercurial-scm.org/D9259

relnotes: copy "next" to "5.6" and clear "next" The same procedure as every year^Wcycle. Differential Revision: https://phab.mercurial-scm.org/D9263

repoview: only pin obsolete wdir parents while there are unresolved conflicts I noticed after doing an update from an obsolete revision with a dirty wdir that the obsolete commit stayed visible for no obvious reason. It was decided in 85b03b1e4715 not to clear mergestate once all of the conflicts were resolved, in order to allow re-resolving. Since the point of pinning the obsolete parents was to allow resolving in the first place (aaeccdb6e654), it makes sense to also gate it on whether or not there are any remaining files to resolve. This might result in pinning again if files are marked unresolved again, but that seems reasonable, given that it still solves the original issue. Note that this isn't purely cosmetic- pushing with a pinned obsolete revision is likely to cause complaints about pushing multiple heads or other unexpected errors. So the faster it comes out of that state, the better. Differential Revision: https://phab.mercurial-scm.org/D9248