Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:12:49 +0800] rev 44807
tests: consistently use pyflakes as a Python module
We check availability of pyflakes as a module, and also running it for real as
a module. Only fair to test filterpyflakes.py working correctly when using
pyflakes as a module too.
This is a graft of a similar fix that ended up on default.
Differential Revision: https://phab.mercurial-scm.org/D8629
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:19:27 +0800] rev 44806
tests: skip pyflakes for mercurial/thirdparty/
The current version of pyflakes (2.2.0) correctly detects one issue:
mercurial/thirdparty/selectors2.py:335:40 '...'.format(...) has unused arguments at position(s): 1
But we're not interested in fixing lint errors in third-party code, so we need
to exclude at least selectors2.py. And in the discussion for this patch it was
decided to just skip the entire thirdparty directory.
This is a graft of a similar fix that ended up on default.
Differential Revision: https://phab.mercurial-scm.org/D8628
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Jun 2020 11:06:22 +0200] rev 44805
zeroconf: fix non existant formatting in the vendored zeroconf module
On Tue Mar 1st 2016 at 09:33:39 timeless decided to wrap long line in
`hgext/zeroconf/Zeroconf.py`. Doing so, he fat fingered a "%w" instead of a "%s"
in a string. %w does not exists, 4 year later, pyflakes (rightfully) complains
about it. So I am fixing it.
Differential Revision: https://phab.mercurial-scm.org/D8627
Adam Hull <adam@hmlad.com> [Fri, 12 Jun 2020 14:22:34 -0700] rev 44804
ignore: note debugignore on ignore man page
It took me a long time to find debugignore. I found the ignore man page
quickly. This change adds a debugging section to the ignore man page
letting people know there is a debug command.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 13 Jun 2020 11:57:58 +0200] rev 44803
nodemap: fix validity checking when revlog is too short
We cannot check the nodeid of a revision that is not even there. We add a simple
fix and simple test.
Manuel Jacob <me@manueljacob.de> [Tue, 09 Jun 2020 05:24:45 +0200] rev 44802
resourceutil: fix location of line comments
These comments slipped out of position when the sources where formatted with
black in 2372284d9457.
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:33:00 -0400] rev 44801
rebase: avoid clobbering wdir() with --dry-run or --confirm (issue6291)
See 56d3e0b499df for the source of adding originalwd to the list of things that
cause wdir to be updated. That change didn't come with tests, and attempts to
recreate the scenario described have thus far failed.
Differential Revision: https://phab.mercurial-scm.org/D8489
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Apr 2020 00:12:11 -0400] rev 44800
tests: show that rebase --dry-run and --confirm wipeout uncommitted changes
It looks like the carnage is limited to rebasing something that is not an
ancestor of wdir(), as both of these abort in a preflight check for that case
with a dirty working directory.
Differential Revision: https://phab.mercurial-scm.org/D8488
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:36 +0530] rev 44799
Added signature for changeset 065704cbdbdb
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:28 +0530] rev 44798
Added tag 5.4.1 for changeset 065704cbdbdb
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 06:40:15 +0200] rev 44797
py3: update comment to account for Python 2 and Python 3 differences
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 07:20:52 +0200] rev 44796
py3: add warning about buffering behavior of pycompat.{stdout,stderr}
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 04:10:37 +0200] rev 44795
tests: fix indentation
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jun 2020 20:40:06 +0900] rev 44794
graft: fix --base value to be saved in state file
'True' just works because it is treated as an integer revision '1' and
only the truthiness of the basectx is important. If multiple source revisions
were supported with --base, the resumed graft operation would go wrong.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:53 +0200] rev 44793
flags: also test merge with executable bit removed
This might catch more bug in the future.
Differential Revision: https://phab.mercurial-scm.org/D8536
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:42 +0200] rev 44792
flags: also test the removal of the exec flag
Differential Revision: https://phab.mercurial-scm.org/D8535
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:31 +0200] rev 44791
flags: read flag from dirstate/disk for workingcopyctx (issue5743)
In 491855ea9d62, various piece of code are moved from committablectx to
workingctx. The reason given is "These read from the dirstate, so they shouldn't
be used in other subclasses."
At least for `flags` this change introduce a bug, because the value flags end up being
read from `_manifest` disregarding the actual state in the working copy (ie: on
disk). When merging exec flag change with renames, this means a new files (the
local content, renamed) is properly written on disk, with the right flags, but
the flags part is later ignored when actually reading flags during merge.
It is not clear to me why the `flags` function was moved, because the code does
not actually hit the dirstate (the reason given in the changeset description).
So I am moving it back to were it comes from and we use a simpler version of
that code (that hit the dirstate everytime) in workingcopyctx. This fix the last
know bug with merging rename and executable byte changes.
Other similar bug might be lurking in 491855ea9d62, but I have not investigated
them.
Differential Revision: https://phab.mercurial-scm.org/D8534
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:19 +0200] rev 44790
flags: actually merge flags in simplemerge
Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when
rename are involved. exec flag change are now properly merged (when merged from
the rename side).
Another bug is affecting this when merging from the side without the rename.
Differential Revision: https://phab.mercurial-scm.org/D8533
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:07 +0200] rev 44789
flags: add a test for merging exec flag change with rename and file change
Changing the file activate other code path that also have bugs… There are two
distinct bugs depending of which side of the merge you stand on. They both
leading to exec flag loss.
We add tests for both, the fix are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8532
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:56 +0200] rev 44788
flags: account for flag change when tracking rename relevant to merge
There are some logic filtering rename to the one relevant to the merge. That
logic was oblivious of flag change, leading to exec flag being dropped when
merged with a renamed.
There are two others bugs affecting this scenario. This patch fix the was where
there is not modification involved except for the flag change. Fixes for the
other bug are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8531
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:44 +0200] rev 44787
flags: also test merging a rename with and exec flag change
This case is currently buggy and was not tested. This is probably a quite old
regression. The next changeset fix this case. Move exec+rename related bug will
gain a test later.
To highlight the expected behavior the currently missing line are marked with (false !)
and the bad one with (true !)
note: we should probably gain explicit "test bool" for this usecases.
Differential Revision: https://phab.mercurial-scm.org/D8530
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:33 +0200] rev 44786
flags: introduce explicit testing for merging change to exec flag
It turns out that we do not seems to test the simple case for merging exec flag
changes. More advanced case are test (merging exec flag without a common
ancestors, merging with a symlink, etc…) but not the basic.
We are about introduce various fixes to merging flag change across renames,
having the most basic case tested first seems useful.
note: We are only testing "adding" an exec flag here, not removing it. We
introduce basic test on stable and will consolidate them on default.
Differential Revision: https://phab.mercurial-scm.org/D8529
Charles Chamberlain <cchamberlain@janestreet.com> [Tue, 26 May 2020 11:14:07 -0400] rev 44785
graft-state: save --base in graft's state, fixing bug with graft --continue
Without this change, running graft --continue after grafting a merge commit using --base
(and encountering conflicts) will output "skipping ungraftable merge revision" even though
we specified a base in the initial graft command.
Graft's improve behaviour is reflected in test-graft.t.
Differential Revision: https://phab.mercurial-scm.org/D8578
Manuel Jacob <me@manueljacob.de> [Fri, 15 May 2020 00:53:37 +0200] rev 44784
setup: raise minimum Python version to 2.7.4
On older Python versions, Mercurial is not really usable because of
https://bugs.python.org/issue10211.
Recently someone reported a crash on the mailing list when running Mercurial
on Python 2.7.3. There was consensus that fixing compatibility for a Python
version more than 7 years old is not worth it. So, instead of making Mercurial
crash with an obscure exception, this patch raises the minimum Python version
to 2.7.4.
Connor Sheehan <sheehan@mozilla.com> [Tue, 19 May 2020 16:18:41 -0400] rev 44783
fsmonitor: coerce `clock` variable to byte-string (issue6321)
Callers of `fsmonitor.state.setlastclock` pass their arguments
wrapped in `pycompat.sysbytes` to ensure the value is a `bytes`
on Python 3. However in `fsmonitor.poststatus.__call__`, if the
return value of `getlastclock()` is `None`, we use the value of
`fsmonitor.poststatus._startclock` instead, which is not converted
to a byte string in the same manner. This commit converts the
value of `startclock` to a byte string using `pycompat.sysbytes`
in the constructor for `poststatus`, to avoid the "`str` + `bytes`"
error from issue 6321.
Differential Revision: https://phab.mercurial-scm.org/D8573
Charles Chamberlain <cchamberlain@janestreet.com> [Thu, 14 May 2020 23:14:24 -0400] rev 44782
py3: change default priority and length used for sorting hooks to be compatible with python 3
The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using
python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''),
(None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is
`TypeError: '<' not supported between instances of 'NoneType' and 'int'`
This fix keeps the same order that was used in python 2 without relying on comparison with
None.
Differential Revision: https://phab.mercurial-scm.org/D8527
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 May 2020 08:31:32 -0700] rev 44781
relnotes: copy "next" to "5.4" and clear "next"
This is the same thing as we've done for the previous few releases.
Differential Revision: https://phab.mercurial-scm.org/D8546
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 May 2020 13:08:02 +0200] rev 44780
dirstate: make sure the dirstate is loaded before the changelog (issue6303)
Before this change, it was possible for the changelog to be loaded before the
dirstate. If a transaction happens betwen the changelog and dirstate reading,
the dirstate can up end poitning toward a revision not existing in the (olded)
changelog. This lead to a warning.
With this revision, we preload the dirstate parent before reading the changelog.
This has a negligible performance impact on performance for all case we are
tracking.
Differential Revision: https://phab.mercurial-scm.org/D8528