Raphaël Gomès <rgomes@octobus.net> [Fri, 19 Feb 2021 17:52:04 +0100] rev 46530
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Feb 2021 15:44:51 +0530] rev 46529
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Feb 2021 15:37:19 +0530] rev 46528
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 10 Dec 2020 14:25:36 +0100] rev 46527
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
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 10 Feb 2021 17:08:34 +0530] rev 46526
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
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 15 Feb 2021 15:13:20 +0530] rev 46525
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
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Feb 2021 12:29:41 -0800] rev 46524
windows: fix parsing of version number to match format from D9955
Differential Revision: https://phab.mercurial-scm.org/D10061
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Feb 2021 12:26:52 -0800] rev 46523
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
Matt Harbison <matt_harbison@yahoo.com> [Fri, 19 Feb 2021 10:04:53 -0500] rev 46522
helptext: fix a recent typo
Differential Revision: https://phab.mercurial-scm.org/D10033
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 24 Feb 2021 15:16:22 +0100] rev 46521
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