rhg: Move subcommand CLI arguments definitions to respective modules Differential Revision: https://phab.mercurial-scm.org/D9968

rhg: replace command structs with functions The `Command` trait was not used in any generic context, and the struct where nothing more than holders for values parsed from CLI arguments to be available to a `run` method. Differential Revision: https://phab.mercurial-scm.org/D9967

rust: Use the DisplayBytes trait in config printing This is similar to `std::fmt::Display`, but for arbitrary bytes instead of Unicode. Writing to an abstract output stream helps avoid allocating intermediate `Vec<u8>` buffers. Differential Revision: https://phab.mercurial-scm.org/D9966

log: respect diff.merge in -p output Differential Revision: https://phab.mercurial-scm.org/D9958

diff: extract function for getting possibly re-merged parent to diff against We'll want to reuse the logic that `hg diff --change` with `diff.merge` uses. At least `hg log -p` should reuse it. This patch therefore extracts that code to a function. Differential Revision: https://phab.mercurial-scm.org/D9957

diff: replace --merge option by config option I can't think of any reason you'd want to enable the merge diff on a run-to-run basis; you'd probably either always or never want it set (though I can't see why you'd never want it set). If you have it set, you'll probably also want the same output in `hg log -p` output. Having a single config option for the feature makes sense. Differential Revision: https://phab.mercurial-scm.org/D9956

tagcache: distinguish between invalid and missing entries The TortoiseHg repo has typically not had a newly applied tag accessible by name for recent releases, for unknown reasons. Deleting and rebuilding the tag cache doesn't fix it, though deleting the cache and running `hg log -r $new_tag` does. Eventually the situation does sort itself out for new clones from the server. In an effort to figure out what the issue is, Pierre-Yves David suggested listing these entries in the debug output more specifically. This isn't complete yet- the second test change that says "missing" is more like "invalid", since it was truncated. The problem there is the code that reads the raw array truncates any partial records and then fills it with 0xFF, which signifies that it is missing. As a side note, that means the check for the length when validating an existing entry never fails. Differential Revision: https://phab.mercurial-scm.org/D9811

branching: merge with stable

hooks: add a `auto` value for `hooks.*run-with-plain` That setting restore the behavior pre-5.6. The current HGPLAIN value is simply passed to the hooks. This allow user who needs it to fully mitigate the behavior change introduced in Mercurial 5.7 by restoring the older behavior. Differential Revision: https://phab.mercurial-scm.org/D9982

hooks: introduce a `:run-with-plain` option for hooks This option control if HGPLAIN should be set or not for the hooks. This is the first step to give user some control of the HGPLAIN setting for they hooks. Some hooks (eg: consistency checking) deserve to be run with HGPLAIN, some other (eg: user set visual helper) might need to respect the user config and setting. So both usage are valid and we need to restore the ability to run -without- HGPLAIN that got lost in Mercurial 5.7. This does not offer a way to restore the pre-5.7 behavior yet (respect whatever HGPLAIN setting from the shell), this will be dealt with in the next changeset. The option name is a bit verbose because implementing this highlighs the need for another option: `:run-if-plain`. That would make it possible for some hooks to be easily disabled if HG PLAIN is set. However such option would be a new feature, not something introduced to mitigate a behavior change introduced in 5.7, so the `:run-if-plain` option belong to the default branch and is not part of this series. Differential Revision: https://phab.mercurial-scm.org/D9981