Fri, 02 Dec 2022 18:04:37 +0100 peer: dissolve `_peerlookup` into its last two callers
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 18:04:37 +0100] rev 49749
peer: dissolve `_peerlookup` into its last two callers This is about to need more changes and the function won't be useful. We do it early to clarify later changes.
Sat, 03 Dec 2022 03:45:45 +0100 peer: stop having a `peer()` method on `peer()`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Dec 2022 03:45:45 +0100] rev 49748
peer: stop having a `peer()` method on `peer()` This is already a peer, why do you want a peer if you already have one.
Sat, 03 Dec 2022 03:45:39 +0100 clone: explicitly detect the need to fetch a peer
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 03 Dec 2022 03:45:39 +0100] rev 49747
clone: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.
Fri, 02 Dec 2022 19:15:04 +0100 addbranchrevs: explicitly detect the need to fetch a peer
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 19:15:04 +0100] rev 49746
addbranchrevs: explicitly detect the need to fetch a peer Instead of having `peer()` method on all `peer()` for this usecase, we could simply handle it explicitly.
Fri, 02 Dec 2022 17:01:54 +0100 path: pass `path` to `peer` in `hg clone`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 17:01:54 +0100] rev 49745
path: pass `path` to `peer` in `hg clone` We directly use the `path` object to build the `peer` object.
Fri, 02 Dec 2022 16:49:54 +0100 path: use `get_clone_path_obj` in share
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 16:49:54 +0100] rev 49744
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.
Fri, 02 Dec 2022 16:42:36 +0100 path: pass `path` to `peer` in mq
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 16:42:36 +0100] rev 49743
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.
Fri, 02 Dec 2022 16:36:43 +0100 path: use `get_clone_path_obj` in _getlocal
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 16:36:43 +0100] rev 49742
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).
Fri, 02 Dec 2022 16:34:00 +0100 path: pass `path` to `peer` in `hg init`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 16:34:00 +0100] rev 49741
path: pass `path` to `peer` in `hg init` We directly use the `path` object to build the `peer` object.
Fri, 02 Dec 2022 16:30:48 +0100 path: add a `get_clone_path_obj` function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 16:30:48 +0100] rev 49740
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.
Fri, 02 Dec 2022 03:56:23 +0100 path: simplify the implementation of `get_clone_path`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 03:56:23 +0100] rev 49739
path: simplify the implementation of `get_clone_path` We can simply use the logic from `get_unique_pull_path_obj` now.
Fri, 02 Dec 2022 03:51:27 +0100 path: clarify document of `get_clone_path`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 02 Dec 2022 03:51:27 +0100] rev 49738
path: clarify document of `get_clone_path` This return a url as `bytes`, not a `path` object.
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 tip