tests: workaround for a flaky test Differential Revision: https://phab.mercurial-scm.org/D9597

revlog: support none compression revlog files had uncompressed revlog entries support since forever, but it wasn't selectable or exposed explicitly. It is occassionally useful for performance testing as it avoids the latency of zlib or zstd. It also has the nice side effect of providing a non-default compression engine out-of-the-box. Differential Revision: https://phab.mercurial-scm.org/D9572

errors: raise InputError on recursive template definition Differential Revision: https://phab.mercurial-scm.org/D9602

errors: raise StateError when push fails because it creates new heads I decided to raise `StateError` here because the local and remote repos are in an incompatible state. I think remote errors (exit code 100) should be when something goes wrong on the remote and there's nothing the user can do. Differential Revision: https://phab.mercurial-scm.org/D9391

errors: raise InputError on early parse error in dispatch I didn't think this would have any effect on the tests, but it does because the catching in `scmutil.callcatch()` still happens. That's because `dispatch` passes in the function that includes the parsing as an argument to that function. I initially used `ConfigError` here but Matt Harbison convinced me to use `InputError`. I think that makes sense since error is not in a config file. Differential Revision: https://phab.mercurial-scm.org/D9387

errors: raise more specifc errors from narrowcommands Differential Revision: https://phab.mercurial-scm.org/D9386

errors: use detailed exit code 50 for StorageError This is done as part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9601

errors: raise InputError if an ambiguous revision id prefix is used It's long bothered me that we include the "00changelog.i" part in a message to the user. This fixes that along with the exit code. Differential Revision: https://phab.mercurial-scm.org/D9600

localrepo: delete obsolete comment about `prefix in repo` raising exception We dropped support for `prefix in repo`, where `prefix` is a hex prefix, in 8b86acc7aa64 (context: drop support for looking up context by ambiguous changeid (API), 2018-04-28), after having deprecated it a while before that. These days you get a `ProgrammingError` instead if you pass in a short nodeid. Differential Revision: https://phab.mercurial-scm.org/D9599

node: import symbols explicitly There is no point in lazy importing mercurial.node, it is used all over the place anyway. So consistently import the used symbols directly. Fix one file using symbols indirectly via mercurial.revlog. Differential Revision: https://phab.mercurial-scm.org/D9480

branching: merge with stable

debugdiscovery: fix swapped heads and roots Patch provided without comment… Differential Revision: https://phab.mercurial-scm.org/D9566

debugdiscovery: display the number of roundtrip used This is a good metric of the complexity of a discovery process. Differential Revision: https://phab.mercurial-scm.org/D9565

copies: make calculating lazy for dir move detection's "addedfiles" The information calculated here was only needed if (a) --debug was specified, or (b) a directory move was plausibly detected. With tree manifests (especially in my pathological repo and with our custom setup), pre-calculating the `u1` and `u2` can be quite slow, and it's not even necessary in many cases. Let's delay calculating it until we know it's actually necessary. This should have no observable differences in output. ### Performance I ran a rebase command in my pathological repo, rebasing two nodes across several public phase commits, but where no directory copies exist in any of the paths I'm tracking. #### Before ``` Time (mean ± σ): 3.711 s ± 0.061 s [User: 0.3 ms, System: 1.5 ms] Range (min … max): 3.640 s … 3.827 s 10 runs ``` #### After ``` Time (mean ± σ): 868.3 ms ± 10.1 ms [User: 0.5 ms, System: 1.2 ms] Range (min … max): 856.6 ms … 883.6 ms 10 runs ``` Differential Revision: https://phab.mercurial-scm.org/D9567

mergetools: add new conflict marker format with diffs in I use 3-way conflict markers. Often when I resolve them, I manually compare one the base with one side and apply the differences to the other side. That can be hard when the conflict marker is large. This patch introduces a new type of conflict marker, which I'm hoping will make it easier to resolve conflicts. The new format uses `<<<<<<<` and `>>>>>>>` to open and close the markers, just like our existing 2-way and 3-way conflict markers. Instead of having 2 or 3 snapshots (left+right or left+base+right), it has a sequence of diffs. A diff looks like this: ``` ------- base +++++++ left a -b +c d ``` A diff that adds one side ("diff from nothing") has a `=======` header instead and does not have have `+` prefixed on its lines. A regular 3-way merge can be viewed as adding one side plus a diff between the base and the other side. It thus has two ways of being represented, depending on which side is being diffed: ``` <<<<<<< ======= left contents on left ------- base +++++++ right contents on -left +right >>>>>>> ``` or ``` <<<<<<< ------- base +++++++ left contents on -right +left ======= right contents on right >>>>>>> ``` I've made it so the new merge tool tries to pick a version that has the most common lines (no difference in the example above). I've called the new tool "mergediff" to stick to the convention of starting with "merge" if the tool tries a regular 3-way merge. The idea came from my pet VCS (placeholder name `jj`), which has support for octopus merges and other ways of ending up with merges of more than 3 versions. I wanted to be able to represent such conflicts in the working copy and therefore thought of this format (although I have not yet implemented it in my VCS). I then attended a meeting with Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for showing a similar format, which reminded me to actually attempt this in Mercurial. Differential Revision: https://phab.mercurial-scm.org/D9551

diff: deprecate -r option The new `--from`/`--to` options should be enough to support all the uses cases and are easier to understand, so there is no reason that I'm aware of to use `-r` anymore. Differential Revision: https://phab.mercurial-scm.org/D9564

diff: update synopsis to use --from/--to instead of -r Differential Revision: https://phab.mercurial-scm.org/D9563

diff: describe behavior by using --from/--to instead of varying revision count I very recently updated the documentation to prefer `--from`/`--to` over `-r`, but I missed the plain-text description of how the command behaves when given different numbers of revisions (I guess I just scanned the text for "-r"). This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D9562

histedit: adjust comment describing `edit` action for clarity Differential Revision: https://phab.mercurial-scm.org/D9561

histedit: tweak `edit` message to try and guide users to our workflow histedit predates evolve, so it drops you on an _uncommitted_ version of the commit you're amending/splitting, which is in contrast to git which expects you to use `git commit --amend` (I think - I'm basing this on internal bug reports). My hope is that this output will guide users a little more towards the expected workflow. Differential Revision: https://phab.mercurial-scm.org/D9560

procutil: don't assign stdin to None, use os.devnull instead It will be painful to take care of procutil.stdin being None everywhere. Thanks to Yuya who recommended it.

dispatch: move IOError handling and flushing of streams to `dispatch()` Instead of patching both dispatch code and commandserver code, we directly handle this in `dispatch.dispatch()`. Thanks to Yuya who recommended this.

simplemerge: write output only once it's complete `simplemerge()` can write either to `ui.fout` or to the file context (for in-memory merge). This patch simplifies the code a bit by making it build the output the same way regardless of where it's written, and then writes the whole output at once. I don't think it will be a problem that we don't output anything until the whole file is merged even if the file is large. Differential Revision: https://phab.mercurial-scm.org/D9550

simplemerge: avoid quadratic concatenation when building output text I haven't checked if the difference is measurable, but the new version is no less readable or idiomatic, so I don't think performance numbers are needed. Differential Revision: https://phab.mercurial-scm.org/D9549

simplemerge: work with opts as native strings instead of bytes There was little reason to use `pycompat.byteskwargs()` in `simplemerge()` as far as I could tell. Differential Revision: https://phab.mercurial-scm.org/D9548

hghave: update the check for virtualenv This started as `hghave --test-features` failing on Windows in `test-hghave.t`. IDK how this worked, as neither my Linux nor Windows machines have the old attribute with virtualenv 20.2.2, even on py2. I think this was noticed recently because 357d8415aa27 mentioned an AttributeError, and mitigated by making this py2 only. But as mentioned, this is also a problem on py2 (where the failure was observed). When I got this working by removing the attribute reference, the command in the test failed because the `--no-site-package` argument was removed some time ago. Therefore, this backs out 357d8415aa27 and references a known good attribute (which was done to suppress the warning about an unused import) that also ensures the command does not need the argument. Since there appears to be (minor) broken stuff on py3, manually apply the `no-py3` guard that was backed out of the check itself. Differential Revision: https://phab.mercurial-scm.org/D9547

singlehead: introduce option to restrict to public changes The new experimental.single-head-per-branch:public-changes-only option restricts the single-head-per-branch filter to public changesets. This is useful when serving one repository with different views as publishing and non-publishing repository. Differential Revision: https://phab.mercurial-scm.org/D9525

treemanifest: stop storing full path for each item in manifest._lazydirs This information is obtainable, if needed, based on the lazydirs key (which is the entry name) and the manifest's `dir()` method. ### Performance This is actually both a memory and a performance improvement, but it's likely to be a very small one in most situations. In the pathological repo I've been using for testing other performance work I've done recently, this reduced the time for a rebase operation (rebasing two commits across a public-phase change that touches a sibling of one of my tracked directories where the common parent is massive (>>10k entries)): #### Before ``` Time (mean ± σ): 4.059 s ± 0.121 s [User: 0.9 ms, System: 0.6 ms] Range (min … max): 3.941 s … 4.352 s 10 runs ``` #### After ``` Time (mean ± σ): 3.707 s ± 0.060 s [User: 0.8 ms, System: 0.8 ms] Range (min … max): 3.648 s … 3.818 s 10 runs ``` Differential Revision: https://phab.mercurial-scm.org/D9553

extensions: avoid including `__index__` in the disabled extension list This generated module contains a dictionary of all bundled extension names and their help for builds that cannot enumerate extensions in the filesystem. The disabled list gets displayed in `hg help extensions`, and is also used by `setup.py` to populate `__index__.py` when building. I haven't seen it sneak into either py2exe or PyOxidizer builds, but it does show up when running tests locally after having created an installer. Differential Revision: https://phab.mercurial-scm.org/D9544

windows: continue looking at `%HOME%` for user config files with py3.8+ The `%HOME%` variable is explicitly called out in `hg help config` as a location that is consulted when reading user files, but python stopped looking at it when expanding '~' in py3.8+.[1] Restore that old functionality by copying in the old implementation (and simplifying it to just use bytes). It could be simplfied further, since only '~' is passed, but I'm not sure yet if we need to make this a generic utility function on Windows. There are other uses of `os.path.expanduser()`, but this is the only case I know of that documents `%HOME%` usage. (The reason for removing it was that it typically isn't set, but it actually is set in MSYS and PowerShell, and `%HOME%` and `%USERPROFILE%` are different in MSYS. I could be convinced to just replace all uses with this as a general utility, so we don't have to think too hard about BC.) [1] https://bugs.python.org/issue36264 Differential Revision: https://phab.mercurial-scm.org/D9559