templater: convert resources to a table of callables for future extension I'm going to add a full templating support to the annotate command. As the annotate is a filectx-oriented command, we'll need a way to look up a ctx from a bounded fctx only when necessary. This is the minimal change to support that. I'm thinking of defining a proper interface to look up template resources to fix other issues, but that isn't ready yet. (Changes from V1: just updated tests and patch descriptions.)

rebase: on abort, don't strip commits that didn't need rebased (issue5822) I clearly missed adding this condition in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Perhaps I should have opted for the "revdone" solution I mentioned there... Differential Revision: https://phab.mercurial-scm.org/D2879

rebase: avoid defining two lists with the same contents In abort(), there's "dstates" and "rebased" that are identical, which they seem to have been since 0806823370d8 (rebase: properly calculate descendant set when aborting (issue3332), 2012-03-22). Let's de-duplicate. I don't know what "dstates" means, but "rebased" makes sense (it's the list of rebased revisions), so let's pick that. Differential Revision: https://phab.mercurial-scm.org/D2878

tests: demonstrate aborted rebase strips commits that didn't need rebasing I haven't verified, but this has probably been broken ever since I added the feature in 78496ac30025 (rebase: allow rebase even if some revisions need no rebase (BC) (issue5422), 2017-05-11). Differential Revision: https://phab.mercurial-scm.org/D2877

merge with stable

hgweb: convert an assert to a ProgrammingError Because assert may get optimized away. Differential Revision: https://phab.mercurial-scm.org/D2882

filemerge: give some variables in _xmerge more descriptive names Differential Revision: https://phab.mercurial-scm.org/D2886

rebase: allow in-memory merge of the working copy parent Before this patch and when the rebase involved the working copy parent (and thus the working copy too), we would not do in-memory rebase even if requested to. The in-code comment explains that the reason had something to do with avoiding an extra update, but I don't know which update that refers to. Perhaps an earlier version of the code used to update to the destination before rebasing even if in-memory rebase was requested? That seems to not be done at least since aa660c1203a9 (rebase: do not bail on uncomitted changes if rebasing in-memory, 2017-12-07). To see if this still made it slower, I create a single tiny commit on top of one branch of the mozilla-unified repo (commit a1098c82 to be exact) and rebased it to another branch (commit d4e9a7be). Before this patch that took 11.8s and after this patch it took 8.6s (I only did two runs each, but the timings were very consistent). Differential Revision: https://phab.mercurial-scm.org/D2876

uncommit: simplify condition for keeping commit We used to keep the commit if it would have become empty and --keep was not passed. Since we just changed it so we also keep it if any patterns were passed on the command line, the only remaining case where we prune the commit is when no arguments were passed and --keep was not passed either, we can simplify the "not files and not allowempty" to just "not allowempty". Let's also rename "allowempty" to "keepcommit" since it's no longer about allowing an empty commit. Differential Revision: https://phab.mercurial-scm.org/D2891

uncommit: document when the commit will be pruned Differential Revision: https://phab.mercurial-scm.org/D2890

uncommit: leave empty commit if all files are uncommitted We had instructions for our internal users to add copy information after commit like this: hg uncommit <srcfile> <dstfile> hg cp --after <srcfile> <dstfile> hg amend That usually works, but if the rename was the only change in that commit, then the commit would get pruned. It's easy to fix the recipe: just pass the --keep option. However, it seems too subtle, so I think this is an indication that the commit should not be pruned if any patterns were given. Differential Revision: https://phab.mercurial-scm.org/D2862

test-template-engine: do not evaluate unused keywords by custom engine If the custom engine, "mytemplater", were installed as the default, it would enter to an infinite recursion at stringify(v) because template keywords may generate a nested mapping containing the same keywords. Spotted by a future patch which will replace context.resource('templ')(...) with context.process(...).