dirstate-v2: fix infinite loop in pure packer Due to the naive approach to path relative-ness, some tree shapes like the one introduced in the associated test could result in the packer going into an endless loop which allocated new `Node` objects endlessly until the process was killed by Linux's OOM killer. Differential Revision: https://phab.mercurial-scm.org/D12170

contrib: refer to RHEL and derivatives instead of CentOS specifically Differential Revision: https://phab.mercurial-scm.org/D12182

packaging: replace centos8 by rockylinux 8 Differential Revision: https://phab.mercurial-scm.org/D12172

rust: fix code formatting Differential Revision: https://phab.mercurial-scm.org/D12173

sparse: rework debugsparse's interface hg debugsparse supports arguments like --include, similar to `hg tracked --addinclude` or `hg log --include`. But in `hg debugsparse`, the pattern is not an argument of the flag, instead the patterns are the anonymous command line arguments. Not only is this surprising, it makes it impossible to use --include and --exclude in the same invocation, or --reset --exclude. So I propose making debugsparse making --include, --exclude take an argument, and rejecting anonymous command line arguments, as well as allowing mixing several of these flags in one invocations. Differential Revision: https://phab.mercurial-scm.org/D12155

color: don't infer vt status from TERM on Windows Previously, it was assumed that Windows environments with "xterm" in the TERM environment variable meant that either "virtual terminal mode" was already enabled, or that we are running in an environment that didn't need a "virtual terminal mode" (such as mintty, that interprets ANSI sequences itself). However, modern Cygwin and MSYS2 set TERM=xterm when using the Command Prompt as the terminal, which needs "virtual terminal mode" to be manually enabled. However, due to (issue6640), the vtmode wasn't being enabled. This patch ensures that we always try to enable vtmode on Windows regardless of the state of TERM, so that: * ANSI-based colors work in modern Cygwin/MSYS2 (with Command Prompt), and * The vtmode is unnecessarily set when running in a different terminal such as mintty, but it is simply redundant and doesn't appear to have ill effects. Differential Revision: https://phab.mercurial-scm.org/D12158

rhg: enable `rhg status` by default, without config or env opt-in The full test suite now passes with `hg` pointing to rhg. Differential Revision: https://phab.mercurial-scm.org/D12162

rhg: Colorize `rhg status` output when appropriate Differential Revision: https://phab.mercurial-scm.org/D12168

rhg: Add support for colored output The same "label" system is used as in Python code Differential Revision: https://phab.mercurial-scm.org/D12167

rhg: Add parsing for the --color global CLI argument Differential Revision: https://phab.mercurial-scm.org/D12166

rhg: Make Ui::new falliable, add Ui::new_infallible This allows propagating color configuration errors Differential Revision: https://phab.mercurial-scm.org/D12165

rhg: Pass a &Config to Ui::new When a Ui object is needed to print errors about configuration-loading errors, an empty (default) configuration is used. Differential Revision: https://phab.mercurial-scm.org/D12164

rhg: Add support for HGPLAINEXPECT Differential Revision: https://phab.mercurial-scm.org/D12163

merge: with stable

help: make the help for `safe-mismatch` real section The extra new lines mean the minirst engine were not seeing them as section… meaning they could not be addressed directly. Differential Revision: https://phab.mercurial-scm.org/D12161