Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 16 Aug 2018 16:36:32 +0300] rev 39167
tests: don't create new repo inside existing repo in test-rebase-inmemory.t
Differential Revision: https://phab.mercurial-scm.org/D4298
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:40:42 -0400] rev 39166
tests: remove test-py3-commands.t
This was a smoke test for early in the Python 3 porting effort, before
anything actually worked. Now that we've got over half the testsuite
passing, this test has outlived its utility.
Differential Revision: https://phab.mercurial-scm.org/D4288
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:41:21 -0400] rev 39165
tests: update test-check-py3-compat.t output in the py3exe branch
This hasn't been maintained in a while, it looks like.
Differential Revision: https://phab.mercurial-scm.org/D4289
Kyle Lippincott <spectral@google.com> [Wed, 15 Aug 2018 17:40:21 -0700] rev 39164
overlayworkingctx: fix exception in metadata-only inmemory merges (issue5960)
If there was a metadata-only mutation, such as +x or -x on a file, we would
create a cache entry with None for data, and this would cause problems later on
when some code tried to run fctx.data() or similar, and was expecting a string.
My original fix for this involved passing data=self._wrappedctx[path].data() in
setflags(), but this version seems slightly better - this way, if we ever call
write() and then call setflags(), we don't destroy the data that we wrote that's
in the cache. I haven't verified that other fields aren't destroyed, such as
date or flags :)
Differential Revision: https://phab.mercurial-scm.org/D4287
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 22:20:28 +0900] rev 39163
filemerge: show actual capabilities of internal merge tools
This information is useful to know which internal merge tools can be
applied safely on binary files and/or symlinks.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Aug 2018 22:24:50 +0900] rev 39162
filemerge: add config knob to check capabilities of internal merge tools
For historical reason, Mercurial assumes capabilities of internal
merge tools as below while examining rules to decide merge tool,
regardless of actual capabilities of them.
=============== ====== ========
specified via binary symlinks
=============== ====== ========
--tool o o
HGMERGE o o
merge-patterns o (*) x (*)
ui.merge x (*) x (*)
=============== ====== ========
This causes:
- unintentional internal merge tool is chosen for binary files via
merge-patterns section of configuration file
- explicit configuration of internal merge tool for symlinks is
ignored unintentionally
But on the other hand, simple "check capability strictly" might break
backward compatibility (e.g. existing merge automations), because it
changes the result of merge tool selection.
Therefore, this patch adds config knob "merge.strict-capability-check"
to control whether capabilities of internal merge tools should be
checked strictly or not.
If this configuration is true, capabilities of internal merge tools
are checked strictly in (*) cases above.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 15 Aug 2018 22:24:38 +0900] rev 39161
filemerge: show warning if chosen tool has no binary files capability
While matching patterns in "merge-patterns" configuration, Mercurial
silently assumes that all merge tools have binary files
capability. This implementation comes from 5af5f0f9d724 (or Mercurial
1.0).
At failure of merging binary files with incorrect internal merge tool,
there is no hint about this silent ignorance of binary files
capability.
This patch shows warning message, if chosen internal merge tool has no
binary files capability. This will help users to investigate why a
binary file isn't merged as expected.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:15:51 +0900] rev 39160
filemerge: add the function to examine a capability of a internal tool
For "symlink" and "binary" capabilities, _toolbool() can not examine
these of internal merge tools strictly, because it examines only
configurations in "merge-tools" section.
Users can configure them explicitly as below for example, but this is
not ordinary usage and not convenient:
[merge-tools]
:other.symlink = true
:other.binary = true
This patch adds hascapability() internal function, which can examine
actual capabilities of a internal merge tool strictly.
At this patch, hascapability() is still used with "strict=False".
Subsequent patches use it with "strict=True".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:08:27 +0900] rev 39159
filemerge: set actual capabilities of internal merge tools
This information is used to detect actual capabilities of internal
merge tools by subsequent patches.
For convenience, this patch assumes that merge tools typed as
"nomerge" have both binary files and symlinks capabilities.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 14 Aug 2018 20:05:36 +0900] rev 39158
help: describe more detail about capabilities while deciding merge tool
"hg help merge-tools" describes as below:
(internal merge tools) will by default not handle symlinks or
binary files.
But in some cases, Mercurial assumes that internal merge tools have
one or both of these capabilities.
"hg help merge-tools" also describes as below, for matching patterns in
merge-patterns configuration section. But this is not sufficient.
Here, binary capabilities of the merge tool are not considered.
This patch describes more detail about capabilities while deciding
merge tool.
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:50:53 -0400] rev 39157
tests: un-glob patchbomb test lines that were only globbing a hostname
Differential Revision: https://phab.mercurial-scm.org/D4296
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:42:04 -0400] rev 39156
tests: force a stable hostname in patchbomb tests
No visible output changes in this commit because everything is globbed
away, but on Python 3 the stable hostname will mean that the headers
don't trigger RFC2822 multi-line mode because they'll always be
consistently short.
Differential Revision: https://phab.mercurial-scm.org/D4295
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:40:20 -0400] rev 39155
patchbomb: allow using HGHOSTNAME to force a hostname
I'll update run-tests.py to set this globally to stabilize some
tests. The variable name is intentionally generic because I suspect we
should generalize this to other tests.
Differential Revision: https://phab.mercurial-scm.org/D4294
Augie Fackler <raf@durin42.com> [Thu, 16 Aug 2018 00:39:32 -0400] rev 39154
patchbomb: extract function for generating message-id
Differential Revision: https://phab.mercurial-scm.org/D4293
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 15 Aug 2018 11:27:57 +0530] rev 39153
rebase: cover restorestatus() by lock to prevent it from being updated
To prevent it from being updated by another process
`restorestatus()` is moved under lock.
Differential Revision: https://phab.mercurial-scm.org/D4282
Martijn Pieters <mj@octobus.net> [Mon, 13 Aug 2018 21:22:14 +0100] rev 39152
branchmap: load branchmap as an iterable
This avoids reading all the file into memory if the cache turns out to be
invalid.
Differential Revision: https://phab.mercurial-scm.org/D4281
Martijn Pieters <mj@octobus.net> [Mon, 13 Aug 2018 20:31:01 +0100] rev 39151
perf: time loading branchmap caches
Differential Revision: https://phab.mercurial-scm.org/D4280
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 00:13:41 +0000] rev 39150
tests: add conditional output when simplestore extensions is loaded
This drops the number of failures with this extension to 3.
Differential Revision: https://phab.mercurial-scm.org/D4286
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 16 Aug 2018 00:11:35 +0000] rev 39149
tests: conditionalize extension tests for extra extensions
If extra extensions are loaded (e.g. via --extra-config-opt),
the tests conditionalized in this commit fail in ways that
are dependent on the extensions that are loaded. So let's
skip them when that scenario is present.
This drops the number of failures for the simplestorerepo.py
extension to 4.
Differential Revision: https://phab.mercurial-scm.org/D4285
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Jul 2018 22:40:39 +0900] rev 39148
commit: try hard to reuse p1 manifest if nothing changed
This is all for commit reproducibility on "hg convert".
With this change, p1 manifest is reused if ctx.files() *to be committed* is
empty, and if new manifest entry is identical to p1. This is important
property for "hg convert" since memctx.files() built from a convert source
may be either a) more narrowed thanks to a committed ctx.files() which
provides more accurate status, or b) containing redundant files because of
sloppy filtering on e.g. octopus merge.
Yuya Nishihara <yuya@tcha.org> [Sun, 12 Aug 2018 18:44:42 +0900] rev 39147
merge: add tests for commit with no content change
It isn't easy to say when to reuse the p1 manifest. Basically, that's only
when wctx.files() is empty, but we need to know that wctx.files() is not
the same as repo['.'].files() after the commit.
This patch adds several examples of commits with empty ctx/wctx.files().
I don't think this is exhaustive, but it contains at least one failure
mode in which a converted repo result in a different hash.
I also note that the manifest revlog does NOT follow the DAG shape of the
changelog since p1 manifest is reused if wctx.files() is empty even at merge.
I don't know whether it is intentional or not, but it's the behavior since
2011, 301725c3df9a "localrepo: reuse parent manifest in commitctx if no files
have changed."
Yuya Nishihara <yuya@tcha.org> [Sat, 07 Jul 2018 22:32:49 +0900] rev 39146
commit: add debug message regarding manifest reuse
Yuya Nishihara <yuya@tcha.org> [Sun, 12 Aug 2018 12:16:08 +0900] rev 39145
mail: convert encoding.encoding to sysstr
Yuya Nishihara <yuya@tcha.org> [Sun, 12 Aug 2018 12:14:28 +0900] rev 39144
mail: call s.decode('ascii') explicitly to see if s is an ascii bytes