py3: avoid changing dictionary during iteration dict.items() and friends are iterators/views in Python 3. You aren't allowed to mutate the underlying dictionary when iterating on these views. So iterate over a copy of things. Differential Revision: https://phab.mercurial-scm.org/D2164

py3: use raw string for key in **kwargs Otherwise Python 3 is unhappy. We only set a single key here. So I don't think pycompat.strkwargs() is necessary. Differential Revision: https://phab.mercurial-scm.org/D2163

py3: preserve chunks as an iterable of bytes patch.diffstat() returns a bytes. util.chunkbuffer() expects an iterable of bytes. Feeding it a single bytes instance on Python 3 will iterate the characters as integers. This blows up util.chunkbuffer. Differential Revision: https://phab.mercurial-scm.org/D2162

py3: use b'' for changegroup version literals Test extensions aren't currently loaded with our custom module importer. # skip-blame b prefix Differential Revision: https://phab.mercurial-scm.org/D2161

py3: use b'' in inline extension # skip-blame b prefix Differential Revision: https://phab.mercurial-scm.org/D2160

py3: use hex(hasher.digest()) .hexdigest() returns a system str. .digest() consistently returns bytes. Differential Revision: https://phab.mercurial-scm.org/D2159

py3: use string for "close" value in commit extras The extras dict on commits has string keys and values. Before this commit, we passed "close" as an integer, which Python 2 gladly coerced to a string during a %s formatting in the bowels of changelog.py. Differential Revision: https://phab.mercurial-scm.org/D2157

py3: catch TypeError during template operations Two places in this code Python 3 changed from raising ValueError to TypeError. So catch the addition exceptions. IMO this code might be better off performing type sniffing. But I'm not sure the implications of changing that. Differential Revision: https://phab.mercurial-scm.org/D2156

py3: use bytes literals for test extension These extensions don't get run through our custom module importer. It's easy enough to make them dual compatible with Python 2 and 3. # skip-blame b prefixes Differential Revision: https://phab.mercurial-scm.org/D2155

py3: use system strings when calling __import__ We must pass the native str type when importing. Differential Revision: https://phab.mercurial-scm.org/D2154

py3: open patches.queue in binary mode And switch to using the context manager form of open() while we're here. Differential Revision: https://phab.mercurial-scm.org/D2153

py3: compare against bytes instead of str Differential Revision: https://phab.mercurial-scm.org/D2152

py3: use b'' in mockblackbox.py This unmasks a ton of other TypeError in blackbox code. # skip-blame since it's just a b prefix Differential Revision: https://phab.mercurial-scm.org/D2175

narrow: add a TODO document These are things that are bigger than we want to handle right now, but are pretty important to get narrowing to be non-experimental. Differential Revision: https://phab.mercurial-scm.org/D2196

tests: use `hello` not `capabilities` over ssh Differential Revision: https://phab.mercurial-scm.org/D2195

narrowwirepeer: add TODO about how we add wireproto args to unbundle :( Differential Revision: https://phab.mercurial-scm.org/D2194

narrowwirepeer: rename expandnarrow capability to exp-expandnarrow The expandnarrow functionality lets a client have a shorthand (for Google it's a reference to a checked-in file) for a set of includes and excludes. For testing we should probably implement a simple version of that functionality here. For now, rename the capability so we don't burn the good name in the future if we need to change behavior. It's plausible that this functionality should be dropped from the narrowhg we ship long-term, but I'm dubious as it seems pretty likely other organizations will want similar shorthands for commonly-used subsets of their trees. Differential Revision: https://phab.mercurial-scm.org/D2193

narrow: make restrictpatterns a little more idiomatic I'm not sure why invalid_includes was an out-param, but it doesn't look like there's any reason for it to be now. Differential Revision: https://phab.mercurial-scm.org/D2192

narrowspec: consistently use set() to copy sets Differential Revision: https://phab.mercurial-scm.org/D2191

narrowspec: document constraints when validating patterns Differential Revision: https://phab.mercurial-scm.org/D2190

narrowrevlog: add a TODO around remotefilelog moving to core We should clean this up considerably when remotefilelog lands, which we expect to try and accomplish in the near-ish future. Differential Revision: https://phab.mercurial-scm.org/D2189

narrowrevlog: add what little I can remember about rename filtering Differential Revision: https://phab.mercurial-scm.org/D2188

manifest: clean up dirlog() to take a d parameter to avoid shadowing dir() Differential Revision: https://phab.mercurial-scm.org/D2187

narrowrevlog: replace AssertionError with ProgrammingError Differential Revision: https://phab.mercurial-scm.org/D2186

narrowrevlog: document excludeddir class and friends Differential Revision: https://phab.mercurial-scm.org/D2185

narrowrepo: add docstring for narrowpats Differential Revision: https://phab.mercurial-scm.org/D2184

narrowtemplates: update to use registrar mechanism It's worth considering at this point if we should just move the two ellipsis functions to core tagged experimental or something, since they're not really narrowing-specific... Differential Revision: https://phab.mercurial-scm.org/D2009

narrow: move from ELLIPSIS_NODE_FLAG to revlog.REVIDX_ELLIPSIS We should have been using this value all along. Sigh. Differential Revision: https://phab.mercurial-scm.org/D2008