largefiles: drop "rel" prefix from filename variables
The prefixes were meant to indicate that these paths are repo-relative
as opposed to absolute. However, that's what the majority of paths in
our code base are, so "rel" made me think they were instead
cwd-relative. Let's just drop the prefixes.
Differential Revision: https://phab.mercurial-scm.org/D5847
branchmap: add some clarifications and clean up flow
- Remove indentation where it is not needed.
- Swap the subset test branches to follow along logically and put the 'empty'
case last.
Differential Revision: https://phab.mercurial-scm.org/D5637
branchmap: updating triggers a write
Rather than separate updating and writing, create a subclass that doesn't write
on update. This minimises chances we forget to write out updates somewhere.
This also makes refactoring and improving the branchmap functionality easier.
Differential Revision: https://phab.mercurial-scm.org/D5636
branchmap: make branchcache responsible for reading
Encapsulate reading in a classmethod, to make it clear what kind of object is
being handled.
This is part of a stack of refactoring changes to help performance improvements
down the line.
Differential Revision: https://phab.mercurial-scm.org/D5635
attr: make some docstrings raw strings
This avoids a SyntaxWarning in Python 3.8 due to invalid
\ escapes.
Differential Revision: https://phab.mercurial-scm.org/D5817
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.
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.
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.
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
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