Kyle Lippincott <spectral@google.com> [Thu, 05 Dec 2019 20:05:08 -0800] rev 43794
packaging: include defaultrc/*.rc instead of default.d/*.rc
Differential Revision: https://phab.mercurial-scm.org/D7555
Augie Fackler <augie@google.com> [Thu, 05 Dec 2019 11:15:19 -0500] rev 43793
merge with stable
Augie Fackler <raf@durin42.com> [Thu, 05 Dec 2019 09:17:38 -0500] rev 43792
Added signature for changeset
a50fecefa691
Augie Fackler <raf@durin42.com> [Thu, 05 Dec 2019 09:17:37 -0500] rev 43791
Added tag 5.2.1 for changeset
a50fecefa691
Kyle Lippincott <spectral@google.com> [Tue, 03 Dec 2019 17:17:57 -0800] rev 43790
py3: make a pycompat.osdevnull, use it in extdiff
Differential Revision: https://phab.mercurial-scm.org/D7545
Kyle Lippincott <spectral@google.com> [Tue, 03 Dec 2019 17:10:10 -0800] rev 43789
subrepo: use pycompat.open directly instead of importing open from pycompat
Differential Revision: https://phab.mercurial-scm.org/D7544
Raphaël Gomès <rgomes@octobus.net> [Fri, 22 Nov 2019 10:39:05 +0100] rev 43788
rust-dirs: address failing tests for `dirs` impl with a temporary fix
https://phab.mercurial-scm.org/D7252 (
5d40317d42b7083b49467502549e25f144888cb3)
introduced a regression in Rust tests.
This is a temporary fix that replicates the behavior of the C and Python impl,
pending the resolution of the discussion (in the phabricator link) about how
we actually want to solve this problem.
Differential Revision: https://phab.mercurial-scm.org/D7503
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Dec 2019 18:46:10 -0500] rev 43787
cleanup: fix docstring formatting
This is just removing the b'' prefix (except demandimportpy2), and making sure
it is triple quoted. I skipped the mapping.py module in zope because that's 3rd
party code.
Differential Revision: https://phab.mercurial-scm.org/D7539
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:42:13 +0100] rev 43786
copies: split the combination of the copies mapping in its own function
In some case, this part take up to 95% of the copy tracing that take about a
hundred second. This poor performance comes from the fact we keep duplciating
and merging dictionary that are mostly similar.
I want to experiment with smarter native code to do this, so I need to isolate
the function first.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 09:39:44 +0100] rev 43785
copies: do not initialize the dictionary with root in changeset copies
We don't strictly need the dict to be prefiled with `{}`. Not doing so will make
the next changeset simpler. This part of a preparation to use native code for
this part of copy tracing.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:42:08 +0100] rev 43784
copies: expand `_chain` variable name to make the function easier to read
This came up while explaining what the function is about. I find the function
easier to follow that way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:45:34 +0100] rev 43783
copies: show we can read data from the "first" mapping
In practice this make no difference since `t` is a copy of `a`. Having this
change before hand will make the next cleanup changeset clearer.
This is work on the road to using some native code for some performance critical
part of copy tracing.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:33:22 +0100] rev 43782
copies: return consistent type from revinfo
The return is expected to be a list, so we should return a list. This make the
use of this function from type-checked language (eg: rust) much simpler.
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 12:44:04 -0800] rev 43781
dateutil: correct default for Ymd in parsedate
The code uses `0` for the default value of Ymd (year, month, and day), which
seems suboptimal. For example, these will fail to parse:
dateutil.parsedate('2000', formats=dateutil.extendeddateformats)
dateutil.parsedate('Jan 2000', formats=dateutil.extendeddateformats)
Fix it by providing sane defaults (1 instead of 0) for year, month, and day.
The suboptimal behavior was introduced by
91bc001a592 (2010-12-29,
"date: fix matching of underspecified date ranges"), which does not seem to
justify the current behavior.
Note end-users should not notice the subtle issue, because there are no formats
in `defaultdateformats` that allow an explicit year with omitted month, or an
explicit month with omitted day.
Differential Revision: https://phab.mercurial-scm.org/D7520
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 12:33:06 -0800] rev 43780
test-doctest: include dateutil
`mercurial.utils.dateutil` has dostrings that contain doctests. Include them.
Differential Revision: https://phab.mercurial-scm.org/D7519
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 11:53:50 -0800] rev 43779
revlog: fix revset in reachableroots docstring
`reachableroots` will only return a subset of `roots` when `includepath` is
False. For example, given the following linear DAG:
2
|
1
|
0
Using roots=0+2, heads=1, the definition in the docstring does not match what
`reachableroots` actually does:
ipdb> repo.changelog.reachableroots(0, roots=[0,2],heads=[1])
[0]
ipdb> repo.revs('heads(::(0+2) & (0+2)::1)')
<baseset+ [1]>
The fix is to do `heads & ::roots` (or `heads & heads::roots`) first, then
select their ancestors:
ipdb> repo.revs('heads(::((0+2) & (0+2)::1))')
<baseset+ [0]>
The docstring was introduced by
fd92bfbbe02d9 (2015-06-19 "revset: rename
revsbetween to reachableroots and add an argument"), which introduced the
`includepath=False` behavior for graphlog grandparents use-case. I believe
the docstring instead of the code should be changed because changing the
code to match the docstring can result in suboptimal graphlog like:
o
:\
: o
: :
:/
o
As opposite to the current "linearized" graphlog:
o
|
o
:
o
Differential Revision: https://phab.mercurial-scm.org/D7518
Kyle Lippincott <spectral@google.com> [Tue, 19 Nov 2019 18:38:17 -0800] rev 43778
lock: pass "success" boolean to _afterlock callbacks
This lets the callback decide if it should actually run or not. I suspect that
most callbacks (and hooks) *should not* run in this scenario, but I'm trying
to not break any existing behavior. `persistmanifestcache`, however, seems
actively dangerous to run: we just encountered an exception and the repo is in
an unknown state (hopefully a consistent one due to transactions, but this is
not 100% guaranteed), and the data we cache may be based on this unknown
state.
This was observed by our users since we wrap some of the functions that
persistmanifestcache calls and it expects that the repo object is in a certain
state that we'd set up earlier. If the user hits ctrl-c before we establish
that state, we end up crashing there. I'm going to make that extension
resilient to this issue, but figured it might be a common issue and should be
handled here as well instead of just working around the issue.
Differential Revision: https://phab.mercurial-scm.org/D7459
Martin von Zweigbergk <martinvonz@google.com> [Fri, 22 Nov 2019 11:08:59 -0800] rev 43777
relnotes: add note about changes to match.{explicit,reverse}dir
Differential Revision: https://phab.mercurial-scm.org/D7508
Yuya Nishihara <yuya@tcha.org> [Thu, 21 Nov 2019 22:43:01 +0900] rev 43776
graphlog: change state dict to attr struct
This should help static analysis.
Yuya Nishihara <yuya@tcha.org> [Thu, 21 Nov 2019 22:52:23 +0900] rev 43775
status: fix default value of status struct
The default argument isn't overloaded. Before, the default constructor would
create a struct having 7 list type objects.
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Nov 2019 23:53:12 +0900] rev 43774
typing: fix return type of logcmdutil.getrevs()
Fixes the following errors:
Invalid type annotation "'Tuple[smartset.BaseSet, changesetdiffer]'"
[invalid-annotation]
No attribute 'BaseSet' on module 'mercurial.smartset'
getrevs: bad option in return type [bad-return-type]
Expected: Tuple[mercurial.smartset.abstractsmartset, changesetdiffer]
Actually returned: Tuple[mercurial.smartset.baseset, None]
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Nov 2019 23:49:05 +0900] rev 43773
typing: consolidate "if not globals():" trick
Removes redundant inline comments. I think pycompat is good place to host
this kind of constants.
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Nov 2019 23:19:57 +0900] rev 43772
rust-cpython: do not convert warning pattern to utf-8 bytes
On Unix, both Rust Path and Mercurial expect a locale-dependent bytes,
and we don't support Windows yet.
Yuya Nishihara <yuya@tcha.org> [Tue, 19 Nov 2019 23:16:16 +0900] rev 43771
rust-cpython: import utils::files::* function at module level
IIRC, it's common in Rust to call functions with the module prefix.