evolve: rename variable "children" to "child" where it's clearly singular

evolve: remove some unused variables

py3: back out 23323092f0a7 D6623 has now been accepted in Mercurial (commit 83666f011679), so evolve commit 23323092f0a7 (py3: convert _origdoc to sysstr to match __doc__, 2019-07-09) is not longer needed.

branching: merge with stable

touch: fix the inconsistent behavior of divergence catching logic (issue6107) When touching a node, the way we check if it can lead to divergence is we look at the successors sets of the rev being touched. And if there is successor revs exists (excluding the case when that successor set is (A,) for rev A) that means there will be divergence and we warn the user. This works fine but there is still a case (which is not covered by looking at successor sets) which can lead to divergence. That case is: when there is already a revision exists which is divergent to the revision being touched. And performing the touch would revive that "dead" divergence. (Dead because one of the revision is obsolete which is the one we are touching) And to see if there is any rev which is divergent to a particular rev we already have a function which we can use here i.e. `evolvecmd.divergentsets(repo, ctx_being_touched)` Changes in test file demonstrate the fixed behaviour.

touch: add test which shows touch can fail to warn about divergence

touch: clarify some inline documentation

tests: update output for new branch cache messsages from Mercurial This makes tests pass again after Mercurial commit c7d236b55a3e (py3: fix formatting of branchmap log messages with repo.filtername=None, 2019-07-14). CORE-TEST-OUTPUT-UPDATE: c7d236b55a3e

metaedit: allow operations on merge commits with some conditions As with fold (see the previous patch), it's allowed to metaedit a merge commit or a set of commits including merge commits (with --fold) as long as there are less than 2 parents of the set not included in the said set.

fold: allow operations on merge commits with some conditions It's possible to fold revision chains that include a single merge commit: just fold everything into the merge commit while saving its other parent (so it continues being a merge commit). It's also possible to fold revisions that include multiple merge commits, on the condition that they merge with not more than 2 external changesets (i.e. a changesets that aren't going to be folded).

rewind: make sure merge commits include files from p1 and p2 Otherwise rewinding a merge commit makes it lose all changes. This fix populates `updates` argument of rewriteutil.rewrite() with parent changesets. That argument is normally used for folding multiple changesets, but in this case it's simply used to include files from p1 and p2. Usually, rewrite() works fine using ctx.files(), but that function can return an empty list when ctx is a merge commit.

touch: make sure merge commits include files from p1 and p2 Otherwise touching a merge commit makes it lose all changes. This fix populates `updates` argument of rewriteutil.rewrite() with parent changesets. That argument is normally used for folding multiple changesets, but in this case it's simply used to include files from p1 and p2. Usually, rewrite() works fine using ctx.files(), but that function can return an empty list when ctx is a merge commit.

py3: make `import hgext3rd.evolve` work

py3: use bytes for template keyword registrations This makes `import hgext3rd.topic` work.

py3: convert _origdoc to sysstr to match __doc__ It's currently stored as bytes by core, so we need to convert it to match Python's expected type for __doc__. This patch can be dropped if D6623 gets accepted.

py3: use bytes for revset predicate registrations

py3: use bytes for wireprotocol command registration

py3: use byte strings for @command registrations

py3: switch from iteritems() to items()

py3: make metadata values be byte strings as Mercurial expects

tests: update output for shorted prompts from Mercurial This makes tests pass again after Mercurial commits f802a75da585 (patch: use a short, fixed-size message for last line of prompt (issue6158), 2019-06-20). CORE-TEST-OUTPUT-UPDATE: f802a75da585

tests: update output for shorted prompts from Mercurial This makes tests pass again after Mercurial commits 4764e8436b2a (filemerge: make last line of prompts <40 english chars (issue6158), 2019-06-20) CORE-TEST-OUTPUT-UPDATE: 4764e8436b2a

rewriteutil: allow rewriting merge commits (issue4561) This patch simply allows rewriteutil.rewrite() to work with commits with multiple parents (i.e. merges). That function is used in such commands as fold, metaedit, touch, rewind. The issue 4561 is marked as easy, the limitation is called unnecessary, no tests fail after this change. What can go wrong.

tests: show what happens when trying to hg touch a merge commit

evolve: further clarify that update is performed only when requested Text further modified by Pierre-Yves David and Anton Shestakov.

touch: let's not use util.acceptintervention() as it's not required

branching: merge with stable

evolve: use right value for branch name when finding branch heads subbranch already formatted as "branchname:topicname", again appending it with ":topicname" doesn't not make sense. It's a little bit surprising that no tests fails though.

evolve: fix confusion in branch heads checking logic when topic in play To provide some context, when topics are in play the branchmap cache we store contains the branch info of a rev as "branch:topic" format IIUC. Assuming that is right, now in present code we don't actually cover this part that "when looking for branch heads where we also have active topic we should look for branch='branch_name:topic' instead". And we get wrong branch heads as a result. This patch make sure that we pass right candidate to find branch heads using branchmap.branchheads() by overriding the localrepo.branchheads() Changes in test file reflect the fixed behavior.

topic: add tests to demonstrate topic confuses the branchhead checking logic While topics are in play, we store the branchheads (which has a topic) in "branchname:topicname" format. After digging into it I found that even in the case when we should have branch heads for "bname:tname" we get heads for "bname". The tests output reflect the confusion in branch head checking logic. Next patch will be fixing the problem.

evolve: fix the inconsistent behaviour of prune (issue6137) Let's not update to any revision when working directory parent is not related to the revision being pruned. Changes in test file demonstrate the fixed behaviour.

prune: add tests to demonstrate issue6137 Here we can see that prune updates off to the parent revision even when the pruned revision wasn't related with the working directory parent. A follow-up patch will fix this.

compat: fix `setupevolveunfinished` for upstream

prune: update to the successor of wdir also with --pair/--biject (issue6142) When prune is used with --pair flag, we can also update to the successor of working directory parent. No need to check len(sucs) or len(precs) here because there's a check for that earlier in the code (it's a requirement of biject). The tests are now demonstrate the correct behavior: when rev 14 was pruned with 12 as its successor, the bookmark that was on 14 was moved to 12. That bookmark was also activated (even before this patch).

tests: demonstrate prune --pair not moving bookmark correctly After `mkcommit n2` line the bookmark is on the correct changeset, but when we prune --pair the two newly created changesets (revs 13 and 14), the bookmark gets moved to their ancestor (rev 0). Instead, it should've moved to the last of their successors (rev 12).

oops: backed out changeset 7ac40b4ea24c Anton requested some changes on it.

compat: fix `setupevolveunfinished` for upstream

evolve: fix the code flow pattern of solving obswdir par and troubled revs Now we will go to _handlenotrouble() (which prints messages about no revs to solve) only when there is no troubled revs and working dir parent is not obsolete. This change also saves us from an issue which was about looking into the revset (smartset contains troubled revs to solve) when a rev from the revset gets hidden. This happens in the case when our wdir parent is obsolete. After resolving obswdir parent we were looking into the revset to check if there is any troubled revs to solve but we should have performed this check before performing the obswdir resolution. Changes in test file reflect this fixed behaviour.

evolve: refactor for consistent behavior of evolve when wdp is obsolete This patch make sure that when working directory parent is obsolete `hg evolve` and `hg evolve --all` don't behave differently.

evolve: backout 3027005c42c3 to reintroduce a bug for right fix This patch backout 3027005c42c3 as it was accepted by mistake while it was being "in-discussion" state.

pick: register pickstate as an unfinished state This way pickstate file will indicate that unfinished pick command needs to be dealt with (--continue or --abort) before modifying the repo. Otherwise it would be e.g. possible to commit during an interrupted pick and that's not expected.

pick: rename variable for unfinishedstates

pick: actually delete pickstate if --abort is given Makes pick to be, uh, actually aborted.

evolve: orphans that evolve into nothing don't need successors (issue5967) When continuing to solve an orphan that created no changes (i.e. clean wdir), _completeorphan() used to create an obsmarker that said that the result of that orphan evolution is the currently checked out changeset. That's not a correct obsmarker, because all of the orphan's changes were dropped and so it had no effect on the currently checked out changeset. This is an issue that has only existed when --continu'ing evolve, that's why the fix touches _completeorphan(), but not _solveunstable(). This fix is adapted from a similar "if node is None" block in _finalizerelocate().

tests: demonstrate obsmarker creation after discarding conflicting changes Continued evolve creates an incorrect obsmarker that says 2 is a successor of 1. It's incorrect because 1 was dropped as it created no changes to commit (after conflict resolution that discarded its changes). If evolve does the same thing in one go (e.g. just by using --tool :local and without subsequent need to continue) the obsmarker is correct.

pick: remove transaction on the whole command (issue6037) At its core, pick is a pretty straightforward and well-behaving command, it uses functions already in core hg, it checks that wdir is clean and that changeset to pick is not public, it checks if there happen to be merge conflicts and can be --continue'd later, etc. It is very similar to graft in core (it also uses mergemod.graft function), but it obsoletes the original changeset. However, graft does not experience this incorrect behavior from issue 6037. What happens in the test case for this issue when we pick a revision that touches both "a" and "b": mergemod.graft() takes the original changeset and tries to apply it to the wdir, which results in "b" being marked as newly added and ready to be committed, "a" updated with the new content and being marked as modified, but "a" also has conflicts. Pick correctly notices this and saves its state before asking for user intervention. So far so good. However, when the command raises InterventionRequired to print a user-facing message and exit while being wrapped in repo.transaction() context manager, the latter partially undoes what mergemod.graft() did: it unmarks "b" as added. And when user continues pick, "b" is therefore not tracked and is not included in the resulting commit. The transaction is not useful here, because it doesn't touch wdir (it's still dirty), it doesn't remove pickstate (and other commands will refuse to work until pick --abort or --continue), it just makes "b" untracked. The solution is to use repo.transaction() only to wrap code that writes data to hg store in the final stages of the command after all checks have passed and is not expected to fail on trivial cases like merge conflicts. For example, committing the picked changeset. But since pick uses repo.commit() for that, and because that function already uses a transaction, wrapping it in another transaction doesn't make sense.

tests: demonstrate hg pick forgetting files after conflicts This test currently passes to show that pick is behaving incorrectly.

packaging: follow hg's supported python version (>= 2.7) "Mercurial 4.3 and newer require Python 2.7." (From https://www.mercurial-scm.org/wiki/SupportedPythonVersions) Also add X- prefix, because that's the correct form, apparently. This line can also be removed in future, since "When Debian supported multiple Python versions, X-Python-Version was used, but it is obsolete now as no supported Debian release supports anything other than python2.7." (From https://wiki.debian.org/Python/LibraryStyleGuide) That page also mentions "X-Python3-Version".

packaging: require hg 4.5 also for usage, not just for building

packaging: require mercurial >= 4.5 Otherwise building the doc package fails with: (third party extension evolve requires version 4.5 or newer of Mercurial; disabling) Exception occurred: File "/usr/lib/python2.7/dist-packages/mercurial/help.py", line 624, in help_ raise error.Abort(msg, hint=hint) Abort: no such help topic: evolve

evolve: clarify why returning by adding inline doc

evolve: move a code block to have right value in has_some_val Because of this we were having wrong value of has_some_val and had some buggy behavior which is being fixed by this patch. Fixed behavior is reflected by the changes in test file.

topic: add tests which demonstrate topicset failure of FilteredRepoLookupError When topics are used, it fails to find hidden revs mentioned in a revset as we are not using unfiltered view of repo. Next patch will fix it.

pick: reduce configoverride() scope Merge tool is only needed for merge.graft() (it's what graft in core hg does), so let's make the scope of the ui.configoverride() narrower.

evolve: correct action verb in a message

evolve: internationalize a message This exact message was already wrapped in _() in the same file, just not here.

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.

test: update output to match the parent changesets This amend was forgotten.

topic: add a simple option to reject publishing The option is pretty basic but it can be used as base to build larger feature. The main target for going in this direction is to be able to distinct between user that are "simple contributors" pushing topic for review and the "maintainers" or "automation" that can publish changesets.

compat: adjust `wrapadd` for upstream Mercurial core updated the API in f385ba70e4af.

debian: override default value for SPHINXBUILD in docs/makefile This is the recommended Debian approach. As suggested by Debian Developer Stephen Kitt, use the approach recommended by Debian for building Sphinx documentation. See https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation Also belated credit to Zash on the #mercurial channel on the Freenode IRC network, who suggested the Make variable approach in the first place.

obshashtree: move obshashtree in its own module The code no longer serve a core purpose. We just keep it because the command might be useful. We move it in a dedicated module so that it does not get in the way of other work.

obsdiscovery: drop `obshash` discovery protocol (issue6136) The protocol has been superseeded by stablerange for a long time. It is untested and more and more buggy. Since this is deprecated experimental code in an experimental code, we drop it. We keep the underlying computation and debug command around for now. They might still be useful to looks at repositories

cmdrewrite: use context manager for some locks and transactions These were the trivial cases where I didn't even need to extend the scope of a transaction or change indentation to fix it.

evolve: mention that --all is default, in list of options

touch: use util.acceptintervention() for closing the transaction It will close the transaction on InterventionRequired.

touch: use context manager for locks

touch: extract the logic of touching rev's to its own function This refactoring will also help us in using the context manager for locks in next patches and also help reducing the nested depth.

changelog: mention user merging in the changelog