path: pass `path` to `peer` in `hg clone` We directly use the `path` object to build the `peer` object.

path: use `get_clone_path_obj` in share The return is simpler to use, and this mean less user for the old function. We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in mq We directly use the `path` object to build the `peer` object. There is one case where we don't. We should fix that at the same time as we fix the sub-repo cases.

path: use `get_clone_path_obj` in _getlocal We don't need to feed the `path` object to a `peer` object, but using an higher level function is simpler here (e.g. no subscript access, explicit attribute access).

path: pass `path` to `peer` in `hg init` We directly use the `path` object to build the `peer` object.

path: add a `get_clone_path_obj` function Same logic as the `get_unique_pull_path_obj` function, this give access to the `path` object directly.

path: simplify the implementation of `get_clone_path` We can simply use the logic from `get_unique_pull_path_obj` now.

path: clarify document of `get_clone_path` This return a url as `bytes`, not a `path` object.

path: pass `path` to `peer` in `hg perf::discovery` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in remotefilelog's tests We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg fastannotate` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in infinitepush We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in largefiles We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in narrow We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg fetch` We directly use the `path` object to build the `peer` object.

path: use `get_unique_pull_path_obj` in `hg relink` This is not really needed, but that help removing caller of the older function.

path: pass `path` to `peer` in `hg transplant` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugbackupbundle` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugssl` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg debugdiscovery` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `remote(...)` revset We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg summary` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg identify` We directly use the `path` object to build the `peer` object.

path: introduce a `get_unique_pull_path_obj` function Unlike the previous one, `get_unique_pull_path`, this function return the `path` object, opening more option for the caller. note that this highlight we don't actually need the `repo` argument to `get_pull_paths`, however changing the API would be annoying for third party extensions.

path: simplify the `get_unique_pull_path` function Simply delegate the search to `get_pull_paths` and check how many we got.

path: remove outdated documentation point from `get_unique_push_path` This is no longer true.

path: pass `path` to `peer` in `hg pull` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.

path: pass `path` to `peer` in `hg incoming` We directly use the `path` object to build the `peer` object. We don't use it for sub-repositories yet, which will have to be fixed at some point.

path: pass `path` to `peer` in `hg incoming` bookmark logic We directly use the `path` object to build the `peer` object. Touching this code highlighted that we never honor the branches' information of when doing bookmark level incoming checks.

path: remove outdated documentation point from `get_unique_pull_path` This is no longer true.

path: update `get_unique_pull_path` to point out it returns a url Unlike other functions in this module it returns a url as `bytes` and not a `path` object. Let us point it out in the doc.

changelog-v2: fix the docket `struct` The previous definition used `L` which is actually 4 bytes, while the documentation and intend was to use `Q`, i.e. 8 bytes.

path: pass `path` to `peer` in infinite push We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg histedit` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in the `outgoing` revset We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg summary` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg outgoing` We directly use the `path` object to build the `peer` object.

path: pass `path` to `peer` in `hg bundle` We directly use the `path` object to build the `peer` object.

path: have `peer` constructor accept a `path` object We don't do anything fancy with it yet, but this is an important step towards having the peers aware of their "source" and associated configurations.

path: deprecated the `pushloc` attribute We want to make sure people with use the full featured path "variant".

path: update logic in `perf` to use the push variant when available The command seems currently broken, but at least it won't be broken by us !

path: directly use the push_variant in `infinitepush` We don't need any extra processing now.

path: directly use the push_variant in `hg histedit` outgoing logic We don't need any extra processing now.

path: directly use the push_variant in the `outgoing` revset We don't need any extra processing now.

path: directly use the push_variant in outgoing internals We don't need any extra processing now.

path: directly use the push_variant in `hg summary` We don't need any extra processing now.

path: directly use the push_variant in `hg outgoing` We don't need any extra processing now.

path: directly use the push_variant in `hg push` We don't need any extra processing now.

path: have `get_push_paths` directly return the push variants So the function directly returns usable paths, that should help the callers!

path: add a method to retrieve a "push variant" of a path This gets you the same path, but using the `pushurl` as destination. This opens the way for a lot of different improvements, the one which interests us is having `peer` objects aware of the `path` they came from.

path: move the url parsing and related attribute setting to a method This will make it simpler to reuse this logic in the next changeset.

peer-or-repo: remove the now unused function We do not need it anymore.

peer-or-repo: build a repo directly in the `repo` function We skip the ambiguous _peerorrepo function to explicitly build a repo within the dedicated function. The peer scheme are therefore no longer considered to build the object.

peer-or-repo: build a peer directly in the `peer` function We skip the ambiguous _peerorrepo function to explicitly build a peer within the dedicated function. This mean explicitly getting a peer from an explicitly create repository when necessary.

static-http: have `statichttprepo.instance` return a peer object It previously returned a statichttprepo object which could not be used for anything but creating a peer. So lets put it into the peer bucket with a peer behavior.

scheme: move the drive letter checking in its own function This help the readability of the main function as is was taking much more room than the main logic.

peer-or-repo: split the scheme between repo and peer Some of the scheme will always produce a peer and some will always produce a repository. So lets use different mapping to reduce the ambiguity.

peer-or-repo: stop relying on AttributeError in `islocal` This will confused pytypes in a future changeset.

repo-or-peer: deprecate calling `islocal` on non-path object There object have a `.local()` method and should use it.

share: stop using 'islocal' with repo instance Having this level of polymorphism of the `islocal` function is weird, and we already have a way to know if the repo is local from the object itself. We are about to deprecate passing a non-bytes object to `islocal`, so clean this up beforehand. We might want to clean up this function too in the future, however this is another adventure.