i18n: merge i18n comments of translatable texts correctly Before this patch, i18n comments of translatable texts are lost at creation of hg.pot file, if: - same translatable text appears multiple times, - the 1st appearance does not have i18n comment, and - any of rest has it For example, previous patch for filemerge.py adds translatable texts with i18n comments, but these comments are lost, because: - automatically added texts in docstring of internal merge tools are picked up earlier than these translatable texts, because of location in filemerge.py - but docstring has no i18n comment This patch makes addentry() of posplit merge i18n comments of later translatable texts, in order to keep them at creation of hg.pot.

help: revise explanation about capability check while selecting merge tool This is follow up of 7c6044634957 and cded904f7acc. This patch adds explanations about: - notation in capability columns in the table - how capabilities of external merge tools are treated

filemerge: avoid putting translated text into docstring This is follow up of my mistake in e09fad982ef5. There is no merge tool, which has only one of binary or symlink capabilities, but this patch lists up all combinations of them for safety in the future. Maybe, it is too paranoid, though.

filemerge: make capability check for internal tools ignore merge-tools section This is follow up of 4d7b11877dd0. Before this patch, capability check of internal merge tools falls back to _toolbool(), which examines configurations in "merge-tools" section. But "hg help config" explicitly says that "merge-tools" section configures external merge tools. Therefore, this patch makes capability check for internal tools in hascapability() always ignore configurations in merge-tools section. In this patch, command line configurations below are added at tests in tests/test-merge-tools.t, in order to confirm that explicit configuration is intentionally ignored at tool selection. --config merge-tools.:INTERNAL_TOOL.CAPABILITY=true

merge with stable

copies: correctly skip directories that have already been considered Previously, `if dsrc in invalid` would never be true, since we added `dsrc +"/"` to invalid, not `dsrc` itself. Since it's much more common for individual files (not whole directories) to be moved, it seemed cleaner to delay appending the "/" until we know we have some directory moves to actually consider. I haven't benchmarked this, but I imagine this is a mild performance win. Differential Revision: https://phab.mercurial-scm.org/D4284

merge with stable