Thu, 01 Dec 2022 01:34:58 +0100 path: directly use the push_variant in `hg outgoing`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:34:58 +0100] rev 49811
path: directly use the push_variant in `hg outgoing` We don't need any extra processing now.
Thu, 01 Dec 2022 01:34:26 +0100 path: directly use the push_variant in `hg push`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:34:26 +0100] rev 49810
path: directly use the push_variant in `hg push` We don't need any extra processing now.
Thu, 01 Dec 2022 01:33:27 +0100 path: have `get_push_paths` directly return the push variants
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:33:27 +0100] rev 49809
path: have `get_push_paths` directly return the push variants So the function directly returns usable paths, that should help the callers!
Thu, 01 Dec 2022 01:32:24 +0100 path: add a method to retrieve a "push variant" of a path
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Dec 2022 01:32:24 +0100] rev 49808
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 tip