destmerge: extract logic based on bookmark into its own function One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.

destupdate: have a generic and extensible way to run each step We want extension to be able to easily override or add new way to select the default update destination. We use the same list + dict approach as in other parts of the code.

destupdate: extract logic based on branch in its own function One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.

destupdate: extract logic based on bookmarks in its own function One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.

destupdate: extract logic based on obsolescence marker in its own function One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.

destupdate: move obsolete handling first This block was overwriting any result from the previous block anyway. So we move it first to prove it is possible and we'll extract it in its own function in the next patch.

destupdate: indent bookmark and branch logic We'll move the obsolete related logic first (as it is overwriting any other anyway) to make the next patch clearer we add indentation in this one.

destupdate: extract validation logic One of the main goal of having consolidated destination function is to allow extension to play with this logic. We extract sub logic to make is wrapping more practical.

rebase: rename and test '_destrebase' We make the name consistent with the other similar revsets and make sure it has minimal tests.

rebase: directly use '_destrebase' There is little value in using the revset instead of the function.

rebase: extra default destination in its own function This makes it much simple to wrap for other extension.

revset: rename and test '_destmerge' We make the name consistent with the one used by '_destupdate' and we ensure the code is run by testing it (abort is expected and merge would).

merge: directly get destination from destutil There is no real value in using the revset over the function. The revset have no remaining users and will be taken care of in a later changesets.

destutil: move default merge destination into a function Function in destutil are much simpler to wrap and more flexible than revset. This also help consistency as 'destupdate' live here and cannot become a pure revset anyway.

revset: reintroduce and experimental revset for update destination The revset is not ready for prime time yet. However it is useful to have some version of it exposed to help candidate users to play with it and provide feedback on what we should aim at. We add a small test to make sure the code runs.

changegroup: move manifest unpacking into its own method The upcoming cg3 will need different logic for unpacking manifests.

changegroup: move manifest packing into a separate function A future change will introduce a new function on a cg3packer that can pack treemanifests as well as flatmanifests.

changegroup: rename manifest linknode closure for clarity Since I'm spending the time to understand this code, I may as well leave it clearer than I found it.

changegroup: reformat packermap and add comment I'm about to add a cg3, and it seems prudent to annotate what formats support what features. It strikes me that we may want to consider moving to a more feature-oriented model in the future, but we'll see how that looks in a little while I guess.

changegroup: document the public surface area of cg?unpackers This should help future readers at least a little.

changegroup: mark cg1unpacker.chunklength as private

changegroup: note why a few methods on cg1unpacker exist I'm not sure what to do abstraction-wise here. It might be more sensible to make a memoryrepo that could apply a bundle in-memory and then we could make the changegroup data be strictly an applyable stream, but that's an idea for Later.

revlog: rename bundle to cg to reflect its nature as a cg?unpacker The new convention is that bundles contain changegroups. bundle1 happens to *only* be a changegroup, but bundle2 is a more featureful container that isn't something you can pass to addgroup().

changegroup: mark _addchangegroupfiles as module-private I'm trying to reason about the public surface area of this module now, so it's worth tagging private things as such.

changegroup: delete now-unused addchangegroup method

localrepo: use cg?unpacker.apply() instead of changegroup.addchangegroup() This is in localpeer, so it lives. Had it been in localrepo instead, I would have tried to exterminate it.

repair: use cg?unpacker.apply() instead of changegroup.addchangegroup()

exchange: use cg?unpacker.apply() instead of changegroup.addchangegroup()

commands: use cg?unpacker.apply() instead of changegroup.addchangegroup()

bundle2: use cg?unpacker.apply() instead of changegroup.addchangegroup()

shelve: use cg?unpacker.apply() instead of changegroup.addchangegroup()

histedit: use cg?unpacker.apply() instead of changegroup.addchangegroup()