test-copies: improve description of the A+B case This will make its role clearer. Differential Revision: https://phab.mercurial-scm.org/D10037

test-copies: use intermediate variable some commit descriptions Right now, everything mostly says "simple merge", we want to use something a bit more descriptive. Before doing any changes, we do most of the churn. This helps the next sets of changesets to be clearer. Differential Revision: https://phab.mercurial-scm.org/D10036

test-copies: don't use empty file for "same content" cases For main case (using filelog or sidedata), this lead to the following hash change. Changesets: - 01c2f5eabdc4ce2bdee42b5f86311955e6c8f573 → 319179230cc87769ab3a861ebffe7a534ebb3d85 - 01c2f5eabdc4 → 319179230cc8 - c72365ee036fca4fb27fd745459bfb6ea1ac6993 → 6cbc9c2b7b391dd738603173717c601648d3735f - c72365ee036f → 6cbc9c2b7b39 File revision for `f`: - 0dd616bc7ab1a111921d95d76f69cda5c2ac539c → cedeacc5bf5d9b9be4d7f8394d33a5349bb29c6e - 0dd616bc7ab1 → cedeacc5bf5d - eb806e34ef6be4c264effd5933d31004ad15a793 → ffb76cd765422a18759a335d8a81fa2bd455be6b - eb806e34ef6b → ffb76cd76542 - 6da5a2eecb9c833f830b67a4972366d49a9a142c → 08d1ff5926fbd0285cdeb044cbe8ab651687e86a - 6da5a2eecb9c → 08d1ff5926fb File revision for `d`: - 7bded9d9da1f7bf9bf7cbfb24fe1e6ccf68ec440 → ba177bbb45ea930ee48469a55d40224537bd57a9 For the "extra in changeset" case we get the following change for file `d`: - 68d5bca9df0577b6bc2ea30ca724e13ead60da81 → b894de5c94aadcb4894ea7c358389819c27fbcce - 68d5bca9df05 → b894de5c94aa - b80de5d138758541c5f05265ad144ab9fa86d1db → 56647659eff080e06e45c18ea9e848836dadea71 - b80de5d13875 → 56647659eff0

narrow: fix flaky behavior described in issue6150 This has been plaguing the CI for a good while, and it doesn't appear to have an easy fix proposed yet. The solution in this change is to always do an unambiguous (but expensive) lookup in case of comparison. This should always be correct, albeit suboptimal. Differential Revision: https://phab.mercurial-scm.org/D10034

patch: make diff --git to differentiate b/w file is empty or doesn't exists Before this patch, as we didn't differentiate the two cases of a file in a context: 1. File doesn't exists 2. File is empty which causes the blob id to be same for both the cases. Now we use `nullhex` for a file which doesn't exists in a context (aligning it with the git diff format) Changes in test file reflect the fixed behavior. Differential Revision: https://phab.mercurial-scm.org/D10001

tests: add a test to demonstrate a bug in `hg diff --git` (issue6486) Issue url: https://bz.mercurial-scm.org/show_bug.cgi?id=6486 This will be fixed in next patch. Differential Revision: https://phab.mercurial-scm.org/D10000

test-copies: reinstall initial identical (empty) files for chained copied This effectively back out changeset deeb215be337. Changeset deeb215be33 does not really include a justification for its change and make mes uncomfortable. I have been thinking about it and they are two options: - either having empty/full files does not make a difference, and deeb215be337 is a gratuitous changes. - either having empty/full files do make a difference and deeb215be33 silently change the test coverage. In such situation if we want the "not empty" case to be tested, we should add new cases to cover them In practice, we know that the "file content did not change, but merge still need to create a new filenode" case exists (for example if merging result in similar content but both parent of the file need to be recorded), and that such case are easy to miss/mess-up in the tests. Having all the file using the same (empty) content was done on purpose to increase the coverage of such corner case. As a result I am reinstalling the previous test situation. To increase the coverage of some case involving content-merge in test-copies-chain-merge.t, we will add a new, dedicated, cases later in this series, once various cleanup and test improvement have been set in place. This changeset starts with reinstalling the previous situation as (1) it is more fragile, so I am more confided getting it back in the initial situation, (2) I have specific test further down the line that are base on these one. The next changeset will slightly alter the test to use non-empty files for these tests (with identical content). It should help to make the initial intent "merge file with identical content" clearer. I am still using a two steps (backout, then change content) approach to facilitate careful validation of the output change. Doing so has a large impact on the output of the "copy info in changeset extra" variant added in 5e72827dae1e (2 changesets after deeb215be33). It seems to highlight various breakage when merge without content change are involved, this is a good example of why we want to explicitly test theses cases. Because the different -do- matters a lot. Fixing the "copy info in changeset extra" is not a priority here. Because (1) this changeset does not break anything, it only highlight that they were always broken. (2) the only people using "copy info in changeset extra" do not have merge. Differential Revision: https://phab.mercurial-scm.org/D9587

upgrade: speed up when we have only nodemap to downgrade Similar to what we do on upgrade, if we have only persistent-nodemap to downgrade we will just delete the nodemap files and update repository requirements instead of processing all the revlogs. After downgrade, we are left with unrequired docket and transaction files which seems fine but can work on deleting them if someone feels we should. Differential Revision: https://phab.mercurial-scm.org/D9992

upgrade: write nodemap for manifests too In 98e39f04d60e I assumed that writing nodemap for manifests was not desirable and stopped writing it during upgrade. However in recent discussion with Pierre-Yves, I learnt that that's not true. Differential Revision: https://phab.mercurial-scm.org/D9991

windows: fix parsing of version number to match format from D9955 Differential Revision: https://phab.mercurial-scm.org/D10061

build: make version from .hg_archival.txt consistent with that from .hg/ D9955 changed the version format to replace "-" by "." and to add "hg" before the number representing the distance from the latest tag. However, it missed the "hg" string and added an extra "." to the version string we produce when there's a `.hg_archival.txt`. This patch makes it consistent. Differential Revision: https://phab.mercurial-scm.org/D10060

helptext: fix a recent typo Differential Revision: https://phab.mercurial-scm.org/D10033

re2: byteify some regex used to get check re2 availability Changeset 687b865b95ad failed to properly byteify this because it was a raw string. This went undetected so far because re2 does not seems to be widely tested. Differential Revision: https://phab.mercurial-scm.org/D10064

packaging: add Provides: python3-mercurial and Homepage to debian package There are other packages that depend on python3-mercurial, like debian's mercurial-git, so we should mark ourselves as providing it. I compared the control file we generate to the one that the debian maintainers generate, and noticed several differences: - the Homepage bit. I included this, because why not - a more robust Suggests list that includes a graphical merge tool - a more robust Breaks list - debian's Recommends openssh-client, we only Recommends ca-certificates - a split into `mercurial` and `mercurial-common` (and possibly others?) - a slightly different description Differential Revision: https://phab.mercurial-scm.org/D9983

bundle2: pass the operation source down to the changegroup This is currently not used by anything in core (and redundant with the url), the real source information is much more useful. This is going to be used in sidedata exchange patches coming soon. Differential Revision: https://phab.mercurial-scm.org/D9986

gendoc: use an empty comment so aliases are separated from previous elements For commands like `hg bookmarks`, where there's no `[+] marked option can be specified multiple times`, this causes the final option in the option list to not be the parent of the aliases definition. The aliases section is thus marked as a blockquote like on commands that do have text separating the option list and the aliases definition. Differential Revision: https://phab.mercurial-scm.org/D9990

gendoc: add support for loading extensions from config settings We manage our installation and ship some extensions, enabled by default for our users, that are in hgext3rd or other directories not scanned by this tool by default. We want to generate docs during the build process, and having those docs include the extensions that users don't have to manually enable is desirable. This is *not* desirable for the normal build process, however, and should never be enabled by default. Differential Revision: https://phab.mercurial-scm.org/D9989

gendoc: support defaults on customopts a bit better Without this, a customopt will very likely render like this: ``` -foo does foo (default: <hgext.myextension.MyOpt object at 0x7f31...>) ``` I copied this logic from how this is handled in mercurial/help.py. Differential Revision: https://phab.mercurial-scm.org/D9988

softstrip: fix a reference to an undefined variable `backupfile` wasn't defined if no backup was requested. Let's set it to `None` by default, which matches what regular `repair.strip()` does. Differential Revision: https://phab.mercurial-scm.org/D9985

softstrip: move _bookmarkmovements() call to where it's needed The call to `_bookmarkmovements()` is unrelated to the backup, so let's move it after. Differential Revision: https://phab.mercurial-scm.org/D9984

tests: fix differing output between py2 and py3 db9e33beb0fb broke the tests because of the difference in bytestring repr between py2 and py3. Rather than backout that change for so little, I figured I'd fix it myself. Hopefully Python 2 supports gets dropped very soon. Differential Revision: https://phab.mercurial-scm.org/D9987

build: fake PEP440 versions If the current version is not exactly a tag, use a local version specifier to fix it up. PEP 440 uses the "+" separator and only allows alphanumeric and dot, so use dot for further separations. Old devel build: 5.7+155-a163cc36d06b New devel build: 5.7+hg155.a163cc36d06b Differential Revision: https://phab.mercurial-scm.org/D9955

tests: add a comment in a test that will hopefully save someone some time I spent at least an hour, probably closer to 1.5, trying to figure out what this was complaining about. Hopefully anyone else in my position will see this note and not waste the time. Differential Revision: https://phab.mercurial-scm.org/D9953

changegroup: don't convert revisions to node for duplicate handling The only consumer can handle revision lists fine. Avoid materializing a range if there are no duplicates as optimization. Differential Revision: https://phab.mercurial-scm.org/D9884

revlog: change addgroup callbacks to take revision numbers Differential Revision: https://phab.mercurial-scm.org/D9883

revlog: change addrevision to return the new revision, not node Differential Revision: https://phab.mercurial-scm.org/D9882

revlog: change addrawrevision to return the revision Differential Revision: https://phab.mercurial-scm.org/D9881

revlog: change _addrevision to return the new revision The node is passed as argument already, so returning it is quite pointless. The revision number on the other is useful as it decouples the caller from the revlog internals. Differential Revision: https://phab.mercurial-scm.org/D9880

rhg: add limited support for the `config` sub-command Only with one argument and no flag. This is mostly for testing. Differential Revision: https://phab.mercurial-scm.org/D9972

rhg: Add support for --config CLI arguments Differential Revision: https://phab.mercurial-scm.org/D9971

rhg: Add support for -R and --repository command-line arguments Differential Revision: https://phab.mercurial-scm.org/D9970

rhg: Replace subcommand boilerplate with a macro This removes some repetition, and will avoid additional repetition in the next commit. Differential Revision: https://phab.mercurial-scm.org/D9969

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

hooks: add some test about HGPLAIN setting and hooks In Mercurial 5.7, hooks are now ran with HGPLAIN set, which is a behavior change in. I could not find explicit test about it so I am adding one. The next changesets will introduce more change to help user mitigate the behavior change when needed. Differential Revision: https://phab.mercurial-scm.org/D9979

hooks: forbid ':' in hook name The `:` character is a special separator in the config and it seems same do to the same for hooks. This is necessary to improve the experience around the HGPLAIN behavior change in 5.7. See next changesets for details. Differential Revision: https://phab.mercurial-scm.org/D9978

rust-status: honor matcher when using the dirstate-only fast-path (issue6483) Differential Revision: https://phab.mercurial-scm.org/D9977

status: add test that shows that the Rust implementation has a bug Differential Revision: https://phab.mercurial-scm.org/D9976

tweak-default: no longer enable the experimental return code The change is quite new and undocumented (since it is experimental) so it seems premature to make it available in tweak default. In addition, I am not sure the new return code are frozen yet (eg: some of the initial feedback have not been incorporated). Before the release I doubled check (probably with Martin) that they were not enabled by default and got replied that they were only enabled in the tests. Have I been aware that they have been also enabled in tweak default I would I have lobbied to delay that. I discovered they were in tweak default from users feedback. They found it an unpleasant and unexpected surprise of 5.7. So I suggest we no enable enable this experimental feature for Mercurial 5.7 and revisit this later, when the feature will be more mature. Differential Revision: https://phab.mercurial-scm.org/D9975

rhg: Parse per-repository configuration Differential Revision: https://phab.mercurial-scm.org/D9964