evolvecmd: the proper way to deal with conflicts is to resolve them And it's worth making the suggestion an actual hint.

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 mercurial-4.8 into mercurial-4.7

test-compat: merge mercurial-4.9 into mercurial-4.8

test-compat: merge stable into mercurial-4.9

branching: merge with 9.0.0

branching: merge back with stable

packaging: mark as development versions This help to distinct official release from in progress work.

Added tag 9.0.0 for changeset 756db65030c6

packaging: prepare release 9.0.0

doc: clarify the status of configuration of the obshashrange protocol

changelog: add various missing bits

templatekw: keep compatibility with Mercurial 4.5 This is simple enough to do.

test: adjust output to stable branch We are about to make a release.

branching: merge with stable

templates: don't alias keywords directly Putting the same function twice in the registry results in duplicate doc strings and therefore confusing "hg help template" output.

stack: remove 'topic.' prefix from colors/labels Stack is related to topics, sure, but it is also good enough to be recognized on its own.

stack: handle hash sizes when --debug flag is provided Since showstack() now uses fm.hexfunc() for node hashes, which depends on ui.debugflag, we should handle situations when hashes are full-sized as well.

stack: always provide (full) node hash to non-default --template

stack: remove unnecessary prefix from stack output with non-default --template "index" template keyword already exists (the current iteration of the loop), so "stack_index" it is. It follows the same convention as other template keywords, such as "files_added", "line_number", etc.

stack: provide context to formatter with non-default --template This allows using template keywords that we don't explicitly provide to the formatter, e.g. rev, branch and topic.

stack: leverage labelsgen() to produce all needed labels for fm.write()

stack: check if stack is empty more pythonically

stack: implement __bool__ and __nonzero__

stack: get stack data directly from stack and remove stackdata() stackdata function began its life in 137f8b04901e as a proto-stack: it computed stack revs on its own and only had one property to return, "changesetcount". Later it started to prepare and return more properties, but since b933a8068c17 it was computing revs using a getstack function. And then finally in 17749d9d3968 it started to rely on stack class entirely. It was a good function, but now, when all the logic it provided was factored into stack class, I'd say it's finally time for it to be put to rest.

stack: use stack._revs instead of stack.revs[1:] in external children revset The revset in question excludes all revs that are part of the stack. Using stack.revs[1:] works (rev #0 is stack base, which is not a part of the stack), but using stack._revs is technically more correct, because this variable is specifically designed to hold only revisions that are part of the stack.