help: document meaning of '%' in graphlog output
I added the feature in
14d0e89520a2 (graphlog: use '%' for other
context in merge conflict, 2020-01-28), but I didn't think to look for
documentation until today (because an internal user asked about it).
Differential Revision: https://phab.mercurial-scm.org/D8649
py3: fix broken man page generation, it was generating `(default: NUL*)`
`bytes(default)` was producing things like `(default: \x00)` when handed
non-bytes values such as `1`, `10`, or `True`. The man page generation would
apparently ignore these bytes and produce man pages that had the string
`(default: )`.
Test Plan:
- Ran `cd doc; python3 gendoc.py "hg.1.gendoc"` and grepped for bad output
- Ran `make deb`, extracted the deb, manually inspected `hg.1` file.
Differential Revision: https://phab.mercurial-scm.org/D8639
hg-core: add Operation interface for high-level hg operations
A distinction is made between operations and commands.
An operation is a high-level function of mercurial whereas a command is what is exposed by the cli.
A single command can use several operations to achieve its goal.
Differential Revision: https://phab.mercurial-scm.org/D8608
rust: do a clippy pass
This is the result of running `cargo clippy` on hg-core/hg-cpython and fixing
the lints that do not require too much code churn (and would warrant a separate
commit/complete refactor) and only come from our code (a lot of warnings in
hg-cpython come from `rust-cpython`).
Most of those were good lints, two of them was the linter not being smart
enough (or compiler to get up to `clippy`'s level depending on how you see it).
Maybe in the future we could have `clippy` be part of the CI.
Differential Revision: https://phab.mercurial-scm.org/D8635
py3: fix comparison between int and None
If stop is None, the condition was always false on Python 2, as None compares
smaller than ints. Therefore we make the condition false if stop is None.
py3: avoid using %r format on bytes
Before the patch, the 'b' prefix appeared in the formatted string. Wrapping the
bytes as pycompat.bytestr solves this problem.
Eventually, I think that we should move away from using %r (like
975e517451a6
and
4d6019c0e0ef did), but that would change output of non-ASCII bytes on
Python 2, so we can’t do it on the stable branch. Also, many places continue to
use %r, so it would be a good idea to do the change all at once.
py3: use `%d` for int in % formatting
On Python 3, `%s` is an alias to `%b`, which requires that the object implements
`__bytes__()`, which is not the case for `int`.