Closing the peer is what I was describing as solution 3 in D9019. But I think I was wrong in saying that it doesn't help with calls to logtoprocess in the middle of commands. I also just noticed that does that, in fact. I'll try and find some time to do that.

What's holding this back is lack of py2 compatibility. Although maybe I want to wait it out at this point. Do we expect to drop py3 in a few days, after 5.7 is released for instance?

Oops, sorry, I didn't have black installed, so test-check-format.t was getting skipped. Having installed it now (at version 19.10, because 20.8b is broken), there are indeed formatting issues. Thanks for the fix.

Failing is what the vast majority of commands do when not given enough arguments:

$ hg clone
hg clone: invalid arguments
...
$ hg backout
abort: please specify a revision to backout
$ hg tag
hg tag: invalid arguments
...
$ hg resolve
abort: no action specified
...
$ hg revert
abort: no files or directories specified
...

Raphael should probably chime in, but as a data point, for us, all installations use rust. And they will have to, when we enable persistent-nodemap soon.
The likelihood of bug and performance bugs is probably higher than without rust, for conditions not covered by tests. That being said, I remember only two bugs from the past 6 months, and they were fairly obscure (type error on linux on filesystems that don't respect exec bits, occasional spurious failure in hg clean when it races on the filesystem with something).

I rebased, but there's nothing new here (apart from conflict resolution).
The discussion for py2 support was not super conclusive. But even given that D7258 uses py3 by default except on windows, and the fact the code changed here doesn't run on windows, I think I still need to make this change work with py2, so py2 issues from windows users can still be investigated from linux.

@joerg.sonnenberger are you stating what was discussed at the sprint merely for comparison, or because you'd prefer for this change to be closer to it?

Was that the conclusion? I think I was taking notes and missed it. I thought turning the strip extension into a debugstrip command was already agreed upon a year ago, In fact, D6987 was started back then (and stalled, but that's unrelated).
There's no disagreement that the command is dangerous, that's why it's debugstrip and not strip. That seems like better pushback to me than an extension.

Ok. When I sent this, I thought the py3 switch was further along than it seems to be. I should be able to make this work on py2 (although I think it would merely reduce the chance of deadlock on py2).

I meant for this change to be in addition to D9019, rather than an alternative, for robustness as written in a bit more detail in the commit message of D9019.

In D8581#128072, @marmoute wrote:

It would be nice to have some comments in the test to explain what is exactly test here, it is a bit obscure from just reading the test.

I reworded the description/comment slightly while Augie accepted the revision, in case people care enough to want the modified commit queued.

In D8586#128112, @durin42 wrote:

Doesn't this break HGPLAIN=1 hg files -T'{path|short}\n' or similar?

I don't understand. Do you mean have numbers in the code in addition to the commit description? Seems like too much details.

What's confusing about it? For me, the emphasis is that the slow branch defines the expected behavior, and the other branch is merely an optimization of it.