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
test-doctest: include dateutil
`mercurial.utils.dateutil` has dostrings that contain doctests. Include them.
Differential Revision: https://phab.mercurial-scm.org/D7519
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
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
relnotes: add note about changes to match.{explicit,reverse}dir
Differential Revision: https://phab.mercurial-scm.org/D7508
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.
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]