exthelper: simplify the ability to register filesets Same mechanism as revsets earlier in this series.

exthelper: simplify the ability to register templates Same mechanism as revsets earlier in this series.

exthelper: simplify the ability to register revsets I think this is what Yuya and Boris agreed on.[1] This happens *after* the extsetup phase now (and after the _aftercallback notifications). But this is trivial, mergeable between exthelper instances, and doesn't need to have the extension name supplied when registering. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-December/125888.html

exthelper: support the option argument when registering a command Largefiles uses this 5th argument with push and pull, so this will be tested in the next commit. I assume the reason for unrolling and reforming the tuple in each finalxxxsetup() is to validate that something proper was passed in when registering. But it's better to explode when decorating than during the delayed actual registration.

exthelper: simplify configitem registration

exthelper: avoid a [] default arg to wrapcommand()

configitems: move the default values to the registrar decorator The exthelper refactoring of configitems stopped registering dynamicdefault for everything, which in turn causes a lot of warnings about mismatched defaults. There are a few stragglers- I didn't fix topic-mode because I wasn't sure what the default should be, and the alias for odiff was explicitly given a default for compatibility.

topic: make revsets like foo#stack[-1] work too We remove base commit when n < 0 because it's confusing to see base (which technically isn't a commit inside the stack) at both 0 and -n.

topic: make revsets like 'foo#stack[0]' work 'stack' relation subscript function is another way to refer to s0, s1, etc. But instead of aborting in many cases it will simply return an empty set.

exthelper: remove '_' in final_xxx() function names to conform to hg style

branching: merge with stable

packaging: mark as development version This avoid confusion when installing from source.

Added tag 8.3.3 for changeset 97b18934d6db

packaging: prepare version 8.3.3

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

evolve: detect unresolved conflict during evolve --continue (issue5966) Evolve --continue was ignoring unresolved conflict, proceeding with its operation without any check. This is now fixed. This test case was built and formalized by Matt Harbison and Anton Shestakov.

tests: filter out uninteresting log events Core has new ui.log() calls added (for tracking extension loading and performance, for example), but in test-discovery-obshashrange.t it produces a bunch of lines that are unrelated to the test. So we filter them out to not touch test output. This is inspired by 1de3364320af in core.

test-compat: merge mercurial-4.4 into mercurial-4.3

test-compat: merge mercurial-4.5 into mercurial-4.4

test-compat: merge mercurial-4.6 into mercurial-4.5

test-compat: merge mercurial-4.7 into mercurial-4.6

test-compat: merge stable into mercurial-4.7

linter: silence rightful complains about unused variable

topic: merge _showlasttouched logic into _listtopics Makes --age work with --verbose.

topic: simplify _showlasttouched and _getlasttouched (and its data structure)

branching: merge with stable

split: add a --interactive flag While the interactive mode is useful for end-users, there are some cases where they don't need the interactivity overhead. Moreover, this allow the split command to be used in automated scripts.

split: take file patterns to limit selection on matching file patterns When splitting a big changeset, the user often wants to extract specific files from the changeset while leaving the others files intact. The split command can now be called with multiple file patterns. Only files that match one of the patterns will be shown in the interactive selection. The user will be able to create one or more commits with those files. When the user finishes splitting the matching files, a last commit will be made with the remaining of the files.