Sorry, I had tried installing black, but it was not the right version. After looking some more, pip3 install black is what was needed I think.

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.

I thought it was generally preferred to have the False in the code, for extensions that want to call the function?

It's already possible to control the default, like so:

I didn't mention setup.py --rust because the toplevel readme doesn't mention setup.py, so I don't really know if that's really how mercurial is intended to be built or an implementation detail.

Thanks for the review. Did something go wrong in a rebase? I'm confused as to why there's two self.vfs.unlink calls in the diff displayed by phabricator.

In D6776#100506, @durin42 wrote:

In D6776#100487, @valentin.gatienbaron wrote:

I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.
I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.

Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)

I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.
I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.

(just interested in this change, I don't have any power to actually accept it)