Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 Feb 2021 22:43:16 +0100] rev 46369
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 Feb 2021 21:05:05 +0100] rev 46368
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
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Feb 2021 21:46:29 +0100] rev 46367
rust-status: honor matcher when using the dirstate-only fast-path (issue6483)
Differential Revision: https://phab.mercurial-scm.org/D9977
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Feb 2021 22:01:23 +0100] rev 46366
status: add test that shows that the Rust implementation has a bug
Differential Revision: https://phab.mercurial-scm.org/D9976
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 Feb 2021 19:23:56 +0100] rev 46365
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 10 Feb 2021 00:11:46 +0100] rev 46364
cmdutil: add a missing byte prefix to string introduce in 976b26bdd0d8
The change is missing a the `b'foo'` prefix to make it a bytestring. This lead
to a traceback in some third party extension. It is unclear to me why the
Mercurial test pass without it.
Differential Revision: https://phab.mercurial-scm.org/D9974
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Jan 2021 10:20:58 +0100] rev 46363
relnote: remove the reference to `debugstrip`
The `debug` namespace is not intended for end user and advertising it is a path
to confusion and trouble. I think we should wait for the `admin` namespace to
exists and the command to be available as `admin--strip` before we advertise it.
Differential Revision: https://phab.mercurial-scm.org/D9817
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Thu, 04 Feb 2021 16:59:46 -0500] rev 46362
largefiles: properly pass kwargs into url.open
The url.open function has acquired a lot of kwargs over the years.
When running `hg import http://example.com/hg/diff/1`, since at least
a708e1e4d7a8 in March, 2018, the calling sites for url.open try to
pass a `sendaccept` parameter that largefiles' override doesn't accept.
Currently that stack traces something like this:
Traceback (most recent call last):
File "/tmp/hgtests.sv744r5t/install/bin/hg", line 59, in <module>
dispatch.run()
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 143, in run
status = dispatch(req)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 245, in dispatch
status = _rundispatch(req)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 289, in _rundispatch
ret = _runcatch(req) or 0
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 465, in _runcatch
return _callcatch(ui, _runcatchfunc)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 475, in _callcatch
return scmutil.callcatch(ui, func)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/scmutil.py", line 155, in callcatch
return func()
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 455, in _runcatchfunc
return _dispatch(req)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1259, in _dispatch
lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 913, in runcommand
ret = _runcommand(ui, options, cmd, d)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1270, in _runcommand
return cmdfunc()
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1256, in <lambda>
d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/util.py", line 1867, in check
return func(*args, **kwargs)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/commands.py", line 4184, in import_
patchfile = hg.openpath(ui, patchurl, sendaccept=False)
File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/hg.py", line 181, in openpath
return url.open(ui, path, sendaccept=sendaccept)
TypeError: openlargefile() got an unexpected keyword argument 'sendaccept'
So, just accept and pass along any kwargs of the overridden function.
Yuya Nishihara <yuya@tcha.org> [Thu, 04 Feb 2021 19:56:45 +0900] rev 46361
procutil: extend gui test to detect wayland session (issue6479)
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 02 Feb 2021 23:44:44 +0530] rev 46360
Added signature for changeset 0e2e7300f430
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 02 Feb 2021 23:44:31 +0530] rev 46359
Added tag 5.7 for changeset 0e2e7300f430
Martin von Zweigbergk <martinvonz@google.com> [Fri, 29 Jan 2021 10:32:19 -0800] rev 46358
relnotes: copy "next" to "5.7" and clear "next"
The same procedure as every year^Wcycle.
Differential Revision: https://phab.mercurial-scm.org/D9909
Matt Harbison <matt_harbison@yahoo.com> [Mon, 01 Feb 2021 15:37:03 -0500] rev 46357
relnotes: elaborate on the side effects of hooks having HGPLAIN=1
Differential Revision: https://phab.mercurial-scm.org/D9943
Matt Harbison <matt_harbison@yahoo.com> [Sun, 31 Jan 2021 19:56:52 -0500] rev 46356
packaging: replace a documentation reference to `python3` on Windows
Sadly, there's not `python3.exe` on Windows.
Differential Revision: https://phab.mercurial-scm.org/D9937
Kyle Lippincott <spectral@google.com> [Wed, 27 Jan 2021 10:29:21 -0800] rev 46355
wix: tell ComponentSearch that it is finding a directory (not a file)
This is to fix an issue we've noticed where fresh installations start at
`C:\Program Files\Mercurial`, and then upgrades "walk up" the tree and end up in
`C:\Program Files` and finally `C:\` (where they stay).
ComponentSearch defaults to finding files, which I think means "it produces a
string like `C:\Program Files\Mercurial`", whereas with the type being
explicitly a directory, it would return `C:\Program Files\Mercurial\` (note the
final trailing backslash). Presumably, a latter step then tries to turn that
file name into a proper directory, by removing everything after the last `\`.
This could likely also be fixed by actually searching for the component for
hg.exe itself. That seemed a lot more complicated, as the GUID for hg.exe isn't
known in this file (it's one of the "auto-derived" ones). We could also consider
adding a Condition that I think could check the Property and ensure it's either
empty or ends in a trailing slash, but that would be an installer runtime check
and I'm not convinced it'd actually be useful.
This will *not* cause existing installations that are in one of the bad
directories to fix themselves. Doing that would require a fair amount more
understanding of wix and windows installer than I have, and it *probably*
wouldn't be possible to be 100% correct about it either (there's nothing
preventing a user from intentionally installing it in C:\, though I don't know
why they would do so).
If someone wants to tackle fixing existing installations, I think that the first
installation is actually the only one that shows up in "Add or Remove Programs",
and that its registry keys still exist. You might be able to find something
under HKEY_USERS that lists both the "good" and the "bad" InstallDirs. Mine was
under `HKEY_USERS\S-1-5-18\Software\Mercurial\InstallDir` (C:\), and
`HKEY_USERS\S-1-5-21-..numbers..\Software\Mercurial\InstallDir` (C:\Program
Files\Mercurial). If you find exactly two, with one being the default path, and
the other being a prefix of it, the user almost certainly hit this bug :D
We had originally thought that this bug might be due to unattended
installations/upgrades, but I no longer think that's the case. We were able to
reproduce the issue by uninstalling all copies of Mercurial I could find,
installing one version (it chose the correct location), and then starting the
installer for a different version (higher or lower didn't matter). I did not
need to deal with an unattended or headless installation/upgrade to trigger the
issue, but it's possible that my system was "primed" for this bug to happen
because of a previous unattended installation/upgrade.
Differential Revision: https://phab.mercurial-scm.org/D9891
Matt Harbison <matt_harbison@yahoo.com> [Wed, 27 Jan 2021 00:54:57 -0500] rev 46354
copyright: update to 2021
Differential Revision: https://phab.mercurial-scm.org/D9885
Simon Sapin <simon.sapin@octobus.net> [Thu, 28 Jan 2021 13:15:34 +0100] rev 46353
persistent-nodemap: Fix Rust declarations for Revlog_CAPI signatures
Use Rust’s `libc::ssize_t` as the closest match to C’s `Py_ssize_t`.
See details in test comment.
Going forward we should find a way to have such Rust declarations
auto-generated from C headers at build time,
or auto-checked against them in a test.
Differential Revision: https://phab.mercurial-scm.org/D9901
Simon Sapin <simon.sapin@octobus.net> [Thu, 28 Jan 2021 13:25:37 +0100] rev 46352
persistent-nodemap: add test case reproducing a Rust panic
Thanks to Mitchell Plamann for reporting this bug.
The next commit fixes it.
Differential Revision: https://phab.mercurial-scm.org/D9900
Matt Harbison <matt_harbison@yahoo.com> [Sun, 24 Jan 2021 19:14:50 -0500] rev 46351
packaging: include `windows_curses` when building py2exe
The `_curses.pyd` module was previously being included by py2exe's module
search, but it left out `_curses_panel.pyd`.
Differential Revision: https://phab.mercurial-scm.org/D9857
Matt Harbison <matt_harbison@yahoo.com> [Sun, 24 Jan 2021 19:08:47 -0500] rev 46350
packaging: allow specifying modules to include with py2exe
Maybe this was missing because there wasn't a need for it.
Differential Revision: https://phab.mercurial-scm.org/D9856
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 24 Jan 2021 18:24:11 -0800] rev 46349
contrib: update PyOxidizer to 0.10.3
This is necessary to work around a bug that caused build failures on
current stable with 0.9.0. This patch was used to build the 5.7rc0 Windows
installers.
Differential Revision: https://phab.mercurial-scm.org/D9858
Raphaël Gomès <rgomes@octobus.net> [Fri, 08 Jan 2021 16:58:23 +0100] rev 46348
contrib: stop building rust for every job
This is just wasteful for all steps that do not use Rust.
Differential Revision: https://phab.mercurial-scm.org/D9717
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Jan 2021 23:24:58 -0500] rev 46347
share-safe: fix an abort message that references the experimental requirement
Differential Revision: https://phab.mercurial-scm.org/D9851
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Jan 2021 23:22:12 -0500] rev 46346
doc: fix a formatting error in requirements.txt
Differential Revision: https://phab.mercurial-scm.org/D9850
Matt Harbison <matt_harbison@yahoo.com> [Thu, 21 Jan 2021 23:21:45 -0500] rev 46345
doc: drop the `exp-` prefix from the `share-safe` requirement
I can't tell if we should leave the experimental one around for historical
documentation purposes, but I'm not sure if there's value to doing that.
Differential Revision: https://phab.mercurial-scm.org/D9849
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Jan 2021 12:23:40 +0100] rev 46344
share-share: have the hint issue more consistently and point to the right doc
This should help user in trouble to find solution in the documentation.
Differential Revision: https://phab.mercurial-scm.org/D9841
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Jan 2021 12:13:17 +0100] rev 46343
doc: point to the main share-safe doc in the "mismatch" config
User should be able to find their way with that.
Differential Revision: https://phab.mercurial-scm.org/D9840
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Jan 2021 12:12:31 +0100] rev 46342
doc: improves the share-safe documentation
The associated behavior is now clearer and we point to the other configuration
that control the mismatching behavior.
Differential Revision: https://phab.mercurial-scm.org/D9839
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Jan 2021 12:11:41 +0100] rev 46341
doc: remove the section about share-safe from its verbose gating
The feature is no longer experimental.
Differential Revision: https://phab.mercurial-scm.org/D9838
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 20 Jan 2021 12:08:10 +0100] rev 46340
doc: relocate doc for `share.safe-mismatch.source-safe.warn`
The documentation for the option is now right after its parent configuration:
`share.safe-mismatch.source-safe`
Differential Revision: https://phab.mercurial-scm.org/D9837