Yuya Nishihara <yuya@tcha.org> [Sun, 27 Jan 2019 13:37:37 +0900] rev 41577
revset: leverage getintrange() helper in relation-subscript operation (API)
Now a range expression is parsed by a relation function itself since the
upper layer have no knowledge about the default first/last bounds.
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Jan 2019 13:28:45 +0900] rev 41576
revset: allow to parse single integer as a range
Even though this wouldn't be any useful in followlines(), it helps to unify
range processing.
Yuya Nishihara <yuya@tcha.org> [Sun, 27 Jan 2019 13:18:53 +0900] rev 41575
revset: extract a helper to parse integer range
It's getting common. As a first step, this patch adds getintrange() and
makes followlines() use it.
I wanted to unify the error messages to make the function interface simple,
but I failed to phrase it briefly.
Kyle Lippincott <spectral@google.com> [Thu, 31 Jan 2019 14:47:34 -0800] rev 41574
commit: if interactive, look elsewhere for whitespace settings (BC)
Previously, when doing `commit -i`, we respected `diff.ignorews` and other
whitespace-related settings, which is probably unexpected. The primary reason
for this is to support hgext.record's commandline options, it's probably
accidental that the `[diff]` settings were also considered. See comments on
issue6042 and D5490. This can cause problems (issue5839, issue6042).
It is assumed by the author that the `[diff]` section is primarily for *viewing*
diffs, and that it is unlikely what people intend when attempting to commit or
revert.
With this change, if a user wants the behavior, they can clone their `[diff]`
settings to `commands.commit.interactive.<setting>`. This is thus a mild BC
change, but one I suspect is not going to be relied on by anyone.
Note: while doing a partial commit/revert, we do not know what command the user
is actually running. This means that the split extension, which ends up calling
into this code, will respect the `commands.commit.interactive.<setting>`
settings, and not a hypothetical `commands.split.interactive.<setting>`. This
*also* means that setting `commands.commit.interactive.ignoreblanklines`, for
example, will still cause issue5839. Considering the highly unlikely chance that
a user actually sets `commands.commit.interactive.<setting>`, the author deems
this risk acceptable.
Differential Revision: https://phab.mercurial-scm.org/D5834
Kyle Lippincott <spectral@google.com> [Thu, 31 Jan 2019 14:29:24 -0800] rev 41573
diff: when looking for diff configs, support a configurable prefix
In a future commit, I want to make it possible to have the diff options pulled
from (as an example) `commands.commit.interactive.ignorews`; previously we only
supported this for customizable sections (so this would have needed a
`commit-interactive` section and been named `commit-interactive.ignorews`, which
felt a bit weird.
Differential Revision: https://phab.mercurial-scm.org/D5833
Kyle Lippincott <spectral@google.com> [Thu, 31 Jan 2019 14:27:25 -0800] rev 41572
config: extract diff-related coreconfigitem()s to a helper method
We already have 'annotate' and 'diff' that use the same set of options, and I
want to add more in a followup commit, so I'm attempting to reduce maintenance
burden and duplication by making it possible to register all of them at once.
Differential Revision: https://phab.mercurial-scm.org/D5832
Kyle Lippincott <spectral@google.com> [Mon, 28 Jan 2019 18:05:05 -0800] rev 41571
commit: ignore diff whitespace settings when doing `commit -i` (issue5839)
Previously, we respected options like `diff.ignoreblanklines` and
`diff.ignorews`. This can cause problems when the user is attempting to
actually commit the blank line change. Specifically, the split extension can get
into an infinite loop because it detects that the working copy is not clean, but
when we get the diff we don't see the changes, so it just skips popping up the
chunk selection flow, saying there's no changes to record.
These options are primarily meant for viewing diffs; it is highly unlikely that
someone is actually intending to add extraneous whitespace and have it ignored
if they attempt to interactively commit (but *not* ignored if they
non-interactively commit).
Differential Revision: https://phab.mercurial-scm.org/D5744
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Feb 2019 14:43:26 -0800] rev 41570
tests: add syntax warnings on Python 3.8 in python-zstandard
These are warnings from upstream test code. Let's just acknowledge them
for now. These should go away in a future python-zstandard release :)
Differential Revision: https://phab.mercurial-scm.org/D5846
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Feb 2019 14:38:23 -0800] rev 41569
check-py3-compat: manually format and print warnings
The warnings mechanism may print to stderr on Python 3. Independent buffering
of stdout and stderr can lead to warnings output not being printed properly.
This commit traps warnings when executing individual files and prints
warnings to stdout so output is deterministic.
Differential Revision: https://phab.mercurial-scm.org/D5845
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 04 Feb 2019 14:25:00 -0800] rev 41568
check-py3-compat: provide filename to ast.parse()
This ensures any warning/error messages print a valid filename instead of
potentially '<unknown>'.
Differential Revision: https://phab.mercurial-scm.org/D5844