I'm enthusiastic about this change, and in general a fan of declaring misfeatures in bookmarks exchange bugs. I think it's pretty clear the existing bookmarks exchange behavior isn't right to the point of being buggy.

This is now ready for review: I would be happy to see this land, and have others contribute towards it. I don't know that I have time to do all that needs doing, but would be delighted to mentor others that want to help!

Why can't we add templater support to debugmergestate instead?

In D8035#119861, @marmoute wrote:

See my comment in D8030, the feature is interresting, but it seems to me that we should implement that through regular amend.

Nevermind, I misread.

I think this is obsolete now? Maybe?

Oddly, this had some rejects (I didn't look why) but i"d be happy to see this earlier in the series.

I remain happy with this.

LGTM, would like @marmoute to chime in.

I think I'd prefer debugbackupbundle per marmoute's suggestion.

I like this, but I'm too chicken to queue it.

I'm just not comfortable with the unsafe block here, especially with the comments from @kevincox . That said, if the unsafe can't disappear, it probably needs a pretty thorough explanation of why it's correct for a novice rust reader to follow?

In D7795#119774, @marmoute wrote:

The change seesm good to me. However kevincox proposal to use #[cfg(test)] for pad_node seems worth applying inflight.

In D7972#120504, @valentin.gatienbaron wrote:

I _think_ it's just paranoia. As long as the bundle wasn't woefully corrupt, it shouldn't be a problem. I _think_ if we set some of the [server]-section bundle validation options (which should be cheap enough) we could ditch this completely safely.
As it stands, I'm fine with this patch if someone else has the confidence to push it.

How does the validity of an input bundle affect recover?

(Marking this as wanting changes per discussions about adding some headline numbers in the log message so I stop looking at it until that happens.)

Planned changes:

In D7894#120247, @marmoute wrote:

More throughful benchmarking has arrived.
This is a large win all over the board. The win for the larger repository very significant.

+         3.9e-05          7.1e-05     1.82  internal.index.no_lookup.track_time('mercurial-2018-08-01', 'zlib', 'default', True, True, True, True, False) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython]

[...]

In D7960#120242, @mharbison72 wrote:

I forgot to reply to this last week- I was concerned when the subsequent part of the stack went in without suppressing the per file progress bars here, that the displayed progress bar would be bouncing around randomly. But it wasn't- it was ever increasing like only the main bar was being changed. Any ideas why that would be?

Terrible damage:

In D7960#119477, @mharbison72 wrote:

In D7960#119446, @marmoute wrote:

(also, the double sending is very sad, could we have a small wireprotocol command dedicated at testing authentication first instead ?)

Presumably, but IDK anything about the wire protocol, and the existing code would still be needed for the case where the server doesn't know about the command.

I'm a huge fan.

Forgot to say: I'd be a big fan of unwinding pycompat.open() now that we're done with the module transformer.

Looks fine to me for default, queued.

In D7972#120111, @pulkit wrote:

Sorry for late reply. By changing the default, I am afraid about the cases where a user has broken repository and we only recover the transaction and don't verify. I am not sure what those cases are. Also I don't know why recover performs verify in the first place. Maybe @durin42, @marmoute or someone else knows?

I need to make some time to clean up the manifest implementation in this to land it, and then we'll need help improving it. It's not dead, just resting. :)

In D7295#118785, @quark wrote:

Have pyre been considered?

In D8030#118489, @martinvonz wrote:

In D8030#118480, @durin42 wrote:

I'm conflicted on rolling the uncopy && amend action into the uncopy command like this. Could users not (without this patch) do hg uncopy foo && hg amend?

I don't think so, because it's not marked as a copy in the working copy, right?

Breaks test-merge2.t but otherwise seems like a good series.