rust-chg: add brief comment about initial capacity of temp_sock_path() I don't know if it can be expressed as a compile-time constant, so it's a comment for now. About this series: This is quite old patches for rust-chg. I heard from Octobus people that there's a plan to do an experiment on merging hgcli + chg + some Rust?, so I decided to respin the rust-chg series. Maybe we'll rewrite the core to leverage the recent async/await functionality, but I want to first make my old patches in so the rust-chg can be a drop-in replacement for the chg of C. Compiler warnings will be removed later, and the codebase will be upgraded to the 2018 edition later. Differential Revision: https://phab.mercurial-scm.org/D8357

discovery: avoid wrongly saying there are nothing to pull We can get in a situation where a revision passed through `hg pull --rev REV` are available on the server, but not a descendant of the advertised server heads. For example the server could lying be during heads advertisement, to hide some pull request. Or obsolete/hidden content could be explicitly pulled. So in this case the lookup associated to `REV` returned successfully, but the normal discovery will find all advertised heads already known locally. This flip a special boolean `anyinc` that will prevent any fetch attempt, preventing `REV` to be pulled over. We add three line of code to detect this case and make sure a pull actually happens. My main target is to make some third party extensions happy (I expect the associated test to move upstream with the extension). However this fix already make some of the `infinitepush` test happier.

rebase: don't create merge when continuing rebase interrupted by old hg This fixes the bug described and demonstrated in the previous commit. It does so by practically undoing 8082a77cc3a2 (rebase: remove some redundant setting of dirstate parents, 2020-01-10). Differential Revision: https://phab.mercurial-scm.org/D8356

tests: demonstrate how continuing rebase after upgrade can result in merge If the user starts a rebase with an hg version before 9c9cfecd4600 (rebase: don't use rebased node as dirstate p2 (BC), 2020-01-10) and then runs into conflicts, they will be dropped out to the shell with the rebased node set as the dirstate's second parent. If they then upgrade to a later hg version, it will respect the dirstate's parents and will create a merge commit even if the user was rebasing a non-merge commit. Differential Revision: https://phab.mercurial-scm.org/D8355

manifest: also declare treemanifest as implementing imanifestdict It always has been intended to be, but it had a mismatched flags() method until the previous change. Differential Revision: https://phab.mercurial-scm.org/D8366

manifest: introduce new exception to signal unavailability of fastdelta() I've spent some time reflecting on this, and I think this is the best we can do in this API contract for now. This opens the door to adding treemanifest's implementation to the list of implementers of imanifestdict. Differential Revision: https://phab.mercurial-scm.org/D8365

copies-tests: remove spurious `]` in the template Fixing this typo happily impact all the tests output. Differential Revision: https://phab.mercurial-scm.org/D8258

merge with stable

debugcommands: fix typo in debuguigetpass

dagop: fix subsetparentswalker to set p1/p2 chains at merge revision The previous implementation was wrong because the '1'/'2' key would be appended at a fork revision. Since we traverse the graph from heads, a merge revision is actually a branching point, where the sort key must be generated.