sparse: fix a py2 based usage of `map()` In a local pytype run, this fixes: File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 386, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '0: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 387, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '1: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]' File "/mnt/c/Users/Matt/hg/hgext/sparse.py", line 388, in debugsparse: unsupported operand type(s) for item retrieval: 'fcounts: Iterator[int]' and '2: int' [unsupported-operands] No attribute '__getitem__' on 'fcounts: Iterator[int]'

histedit: byteify the help for the multifold action While there's some allowance for str in `_()`, it's commented to be for "goofy unicode docstrings in test", so no idea how well that works, but it should at least come back as bytes. With HGPLAIN, however, the str isn't touched and is returned as-is, so this seems like a real bug.

typing: use python3-style type annotation

merge: cache the fs checks made during [_checkunknownfiles] this ~halves the number of lstat calls made when updating from rev(-1) to a revision with lots of files

merge: disable the whole filesystem access loop if [_realfs] is false This makes it clearer that [auditeddir] is only relevant for [_realfs] checkers, and makes the non-realfs checkers more performant.

merge: short-circuit the _checkfs loop upon getting ENOENT This reduces the number of [lstat] calls when updating from rev(-1) to a rev with lots of files by a factor of several: for path foo/bar/baz/quux.txt without this patch we're lstatting: foo foo/bar foo/bar/baz foo/bar/baz/quux.txt and with this patch: foo foo/bar/baz/quux.txt

merge: don't pay for pathconflicts if there are none

pathauditor: no need to normcase the paths The only thing normed paths are used is the key of the caching sets, so the only change of behavior will be that the checks will be repeated for paths that differ by case. If anything, it seems correct for the check to be repeated, in case that actually affects semantics, but the main reasoning is simplifying the code and making it a bit faster. It looks like the code originally comes from commit [081e795c60e0]: it looks like that commit tried to get rid of the existing norming, but presumably did this overly cautiously, preserving it for the cache keys, even though it was pointless even then.

pathutil: slightly faster path audit in the common case

debug: add a config to abort update early This is useful to benchmark the parts of [hg update] that come before the parallel worker.