discovery: fix docstring of `outgoing` class Also, introduce a more correct name `ancestorsof` for what was named `missingheads` before. For now, we just forward `ancestorsof` to `missingheads` until all users are changed. There were some mistakes in the old docstring / name: * `missingheads` (new name: `ancestorsof`) contains the revs whose ancestors are included in the outgoing operation. It may contain non-head revs and revs which are already on the remote, so the name "missingheads" is wrong in two ways. * `missing` contains only ancestors of `missingheads`, so not *all nodes* present in local but not in remote. * `common` might not contain all common revs, e.g. not some that are not an ancestor of `missingheads`. It seems like the misleading name have fostered an actual bug (issue6372), where `outgoing.missingheads` was used assuming that it contains the heads of the missing changesets.

discovery: weaken claim about returned common heads if ancestorsof are given As the test case shows, the claim is not true in general.

cext: remove unused variables Differential Revision: https://phab.mercurial-scm.org/D8760

phabupdate: allow resigning from revisions Differential Revision: https://phab.mercurial-scm.org/D8756

phabupdate: allow revisions to be commandeered Differential Revision: https://phab.mercurial-scm.org/D8755

phabupdate: allow revisions to be reopened Differential Revision: https://phab.mercurial-scm.org/D8754

phabupdate: allow revisions to be marked "closed" (Yes, the transaction name and final state in the comment here do differ.) Differential Revision: https://phab.mercurial-scm.org/D8753

phabupdate: allows revisions to be marked "request-review" Differential Revision: https://phab.mercurial-scm.org/D8752

phabupdate: allow revisions to be marked with "plan changes" Differential Revision: https://phab.mercurial-scm.org/D8751

status: match category text in the option description The ! category in the main status help text is defined as "missing", so use the same text for the help text of --delete. Differential Revision: https://phab.mercurial-scm.org/D8759

purge: classify as a "working directory management" command in help It seems to me that `hg purge` is clearly a "working directory management" command and not a "repository management" command. The working copy is all that's affected, after all; the repo is not affected at all. Differential Revision: https://phab.mercurial-scm.org/D8757

extensions: make `hg help extensions` list disabled extensions with PyOxidizer `setup.py` has a mechanism for generating a list of bundled extensions and their documenation and putting it in a `hgext/__index__.py` file. That file is then read from `extensions.py`, which makes `hg help extensions` work in py2exe binaries. This patch makes it so `setup.py` produces the `hgext/__index__.py` file also when called by PyOxidizer. Thanks to Matt Harbison for pointing out the existence of `__index__.py`! Differential Revision: https://phab.mercurial-scm.org/D8758

phases: sparsify phaseroots and phasesets As final step of dealing with the holes in the phase numbers, make phaseroots and phasesets both dictionaries indexed by the phase number. Further adjust the interface of the C module by pushing the node to revision mapping down as it is cheaper on the C side to deal with revision numbers. Overall, the patch series improves a no-change "hg up" for my NetBSD test repository from 4.7s to 1.3s. Differential Revision: https://phab.mercurial-scm.org/D8698

extdiff: add some comments in diffrevs() It was not obvious to understand the code so I added some comments. Differential Revision: https://phab.mercurial-scm.org/D8690

extdiff: add comments and minor variable renames diffpatch() Some variable names were now confusing as we refactored the code in a separate function. For example, `node1a` leads to ideas why `1a` and not `1`. The variable storing path to patch file was named as `dirX` instead of `fileX`. Renamed these variables and added couple of comments. Differential Revision: https://phab.mercurial-scm.org/D8689

extdiff: remove unrequired do3way argument to diffpatch() When we are diffing patches, there is no 3 way diff. Differential Revision: https://phab.mercurial-scm.org/D8688

extdiff: refactor logic to diff revs of versions of files Now that code for both cases, diffing patches or files is in separate function, it will be better to refactor them more and understand. Differential Revision: https://phab.mercurial-scm.org/D8687

extdiff: refactor logic which does diff of patches The current extdiff code is hard to understand on first look. Took me few hours to grasp the code. Before adding more things, decided to do some refactoring. Differential Revision: https://phab.mercurial-scm.org/D8686

absorb: make it explicit if empty changeset was created If the config rewrite.empty-successor=skip is set, a message "became empty and was dropped" is shown if the changeset became empty. If the config rewrite.empty-successor=keep is set, absorb may create changesets even if they became empty. It’s probably a good idea to make that explicit. Therefore the message is changed to be a combination of both: "became empty and became ...". Repeating the word "became" is not very elegant. This results from the fact that "became" was and is overloaded to indicate both the change from non-empty to empty and the successor relation. In the combinated message, both meanings are used in one sentence.

absorb: consider rewrite.empty-successor configuration This adds support for the recently added rewrite.empty-successor configuration.

rebase: consider rewrite.empty-successor configuration This adds support for the recently added rewrite.empty-successor configuration.

rewriteutil: add utility to check whether empty successors should be skipped

config: add option to control creation of empty successors during rewrite The default for many history-rewriting commands (e.g. rebase and absorb) is that changesets which would become empty are not created in the target branch. This makes sense if the source branch consists of small fix-up changes. For more advanced workflows that make heavy use of history-editing to create curated patch series, dropping empty changesets is not as important or even undesirable. Some users want to keep the meta-history, e.g. to make finding comments in a code review tool easier or to avoid that divergent bookmarks are created. For that, obsmarkers from the (to-be) empty changeset to the changeset(s) that already made the changes should be added. If a to-be empty changeset is pruned without a successor, adding the obsmarkers is hard because the changeset has to be found within the hidden part of the history. If rebasing in TortoiseHg, it’s easy to miss the fact that the to-be empty changeset was pruned. An empty changeset will function as a reminder that obsmarkers should be added. Martin von Zweigbergk mentioned another advantage. Stripping the successor will de-obsolete the predecessor. If no (empty) successor is created, this won’t be possible. In the future, we may want to consider other behaviors, like e.g. creating the empty successor, but pruning it right away. Therefore this configuration accepts 'skip' and 'keep' instead of being a boolean configuration.

commands: use any() instead of `if a or b or c` Small cleanup for future when we have an option to show configs from shared rc. Differential Revision: https://phab.mercurial-scm.org/D8658