Yuya Nishihara <yuya@tcha.org> [Sat, 05 Jan 2019 15:44:55 +0900] rev 41022
match: fix assertion for fileset with no context (
issue6046)
A falsy changectx should be allowed.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 04 Jan 2019 21:01:10 -0500] rev 41021
templatekw: fix documentation typos
Yuya Nishihara <yuya@tcha.org> [Wed, 02 Jan 2019 09:41:04 +0900] rev 41020
update: do not pass in user revspec as default destination (
issue6044)
When the revsingle() was introduced at
61c0df2b089a, it couldn't handle
revspec=0 (not '0') properly. That's probably why the default was set to
rev.
This is technically BC since "hg update ''" was identical to "hg update '.'"
whereas "hg update -r ''" is "hg update", but I believe that's a bug given
no test fails with this change.
Boris Feld <boris.feld@octobus.net> [Sun, 30 Dec 2018 16:11:06 +0100] rev 41019
revlog: cache delta base value under -1
Such base are invalid so we better report them early.
Boris Feld <boris.feld@octobus.net> [Thu, 27 Dec 2018 23:34:37 +0100] rev 41018
revlog: catch revlog corruption in index_baserev
A revision cannot use a base above itself, it can only happens one corrupted
repository.
Ignoring such corrupted could lead to infinite loop.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 21 Dec 2018 17:36:12 -0500] rev 41017
phabricator: properly encode boolean types in the request body
I tripped over this playing with `hg debugcallconduit` to query for valid
reviewers. If the JSON on stdin is written as 'True' or 'False', python
complains it isn't valid JSON. If it's written as 'true' or 'false', it made it
to the server, but got kicked back with this:
abort: Conduit Error (ERR-CONDUIT-CORE): Error while reading "isBot":
Expected boolean (true or false), got something else.
The test isn't really relevant here (the code can be reverted, and it will
pass), but this gives us coverage for the debug command.
Augie Fackler <augie@google.com> [Thu, 20 Dec 2018 01:26:39 -0500] rev 41016
parsers: better bounds checking in fm1readmarkers
Our Python already calls this with reasonable values consistently, but
my upcoming fuzzer is extremely quick to discover the lack of sanity
checking here.
Differential Revision: https://phab.mercurial-scm.org/D5464
Augie Fackler <augie@google.com> [Wed, 19 Dec 2018 23:48:35 -0500] rev 41015
fuzz: new fuzzer for dirstate parser
Differential Revision: https://phab.mercurial-scm.org/D5463
Augie Fackler <augie@google.com> [Wed, 19 Dec 2018 20:26:53 -0500] rev 41014
fuzz: new fuzzer for revlog's parse_index2 method
Differential Revision: https://phab.mercurial-scm.org/D5462
Augie Fackler <augie@google.com> [Wed, 19 Dec 2018 21:57:23 -0500] rev 41013
fuzz: extract Python initialization to utility package
Avoids code duplication between fuzzers of parsers.so.
Differential Revision: https://phab.mercurial-scm.org/D5461
Augie Fackler <augie@google.com> [Wed, 19 Dec 2018 23:40:37 -0500] rev 41012
fuzz: remove probably-wrong -fsanitize from fuzzutil.o rule
Differential Revision: https://phab.mercurial-scm.org/D5460
Augie Fackler <augie@google.com> [Wed, 19 Dec 2018 23:51:02 -0500] rev 41011
parsers: remove long-dead parse_manifest method
We haven't used this in years, I think it's fine to ditch it now. We
had previously kept it around to ease bisecting with built extensions,
but these days we've got a better versioning scheme anyway. Noticed
this method kicking around while looking in parsers.so for likely
fuzzing targets.
Differential Revision: https://phab.mercurial-scm.org/D5459
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Dec 2018 09:33:42 -0800] rev 41010
help: hide default value for default-off flags
If we no longer show the "[no-]" for default-off flags, it also seems
unnecessary to show the "default: off" for them, since that's quite
clearly the default. It's extra confusing for action flags like `hg
bookmarks --delete`.
Differential Revision: https://phab.mercurial-scm.org/D5455
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Dec 2018 09:20:32 -0800] rev 41009
help: show "[no-]" only for default-on Flags
As Anton (av6) pointed out, the "[no-]" is confusing for action flags
like `hg bookmark --delete`. We could come up with a way of indicating
which flags are action flags (e.g. use None for the default value
instead of False). However, it's probably also unlikely that users
will want to negate even non-action flags like --hidden.
One of the more common flags where the "[no-]" prefix would be useful
is `hg evolve --update`. The reason it's helpful there is that it
defaults to on. So I think we can simply include "[no-]" only for
flags that are on by default (and thus require the user to add the
"[no-]" for the option to have any effect).
Note that there are use cases for negating flags that already off by
default. For example, you may have an alias for `hg log -G --hidden -T
foo` and now want to pass "--no-hidden" to that alias. However, I
think that users who want that are likely to be advanced enough that
they've already learnt about the "no-" prefix by seeing it somewhere
else.
Differential Revision: https://phab.mercurial-scm.org/D5454
Martin von Zweigbergk <martinvonz@google.com> [Wed, 05 Dec 2018 15:37:03 -0800] rev 41008
shelve: drop unnecessary backup of narrowspec
I mechanically added the backup code everywhere in
ad24b581e4d9
(narrow: call narrowspec.{save,restore,clear}backup directly,
2018-08-03), but I can't think of a reason it would be needed in the
shelve code, so let's drop it.
Differential Revision: https://phab.mercurial-scm.org/D5457
Martin von Zweigbergk <martinvonz@google.com> [Mon, 07 May 2018 17:08:17 -0700] rev 41007
shelve: pass transaction around to clarify where it's used
Differential Revision: https://phab.mercurial-scm.org/D5456