CC @wlis since this change will impact Facebook. I'd also appreciate validation of my assertions in the commit message about the behavior of remotefilelog and working directory updates being more I/O than CPU/GIL bound.

I'm OK with this undocumented hack. And there are cases where we may want to test setup.py outside the context of a checkout as well. The important thing is end-users not running Mercurial with Python 3 unknowingly.

I don't understand phases code that well and am not sure if I'll be able to contribute a fix for the underlying issue in the next few days. If someone wants to take a shot at it, I could use the help.

In D3845#60316, @durin42 wrote:

It's been recommended to me that we avoid the streaming flavor of
cbor, so we'd probably just do one-shot messages.

In D3764#59425, @pulkit wrote:

Thinking out loud here: I see that --dry-run for rebase will be very useful for automation. How about returning 1 when there are conflicts and returning 0 when there are no conflicts? Also maybe we should add formatter support to the dry-run output for each command so that automation can read the JSON output and tell user what can happen.

Also, it's worth keeping in mind Python function call overhead when working on this code. I'm optimistic that things that need progress bars won't be concerned about this. But it might be worth measuring and keeping in the back of your head.

The low-level progress API has always bothered me as well.

I'm getting a few test errors applying this against the latest revision of hg repo:

Overall I think this is a great feature! The patch as is needs a bit of UI work.

I think having better display of graph symbols is a compelling end-user feature and should be part of Mercurial.

I'm unsure about this change. On one hand, the comment (which appears to have been added to mpm several years ago) implies that we never should have generated backups in this case. On the other, one of the key rules of a VCS is "don't eat my data." Even though we are aborting the operation, I could see some scenarios where someone would want a backup of the aborted/partially-completed rebase.

I agree with @yuja that we should move this to util.py or one of its siblings and rename it to uninterruptable or some such.

So Python 3 is performing a lot more read(-1) calls than Python 2? That, uh, seems weird and might be worth investigating.

I think this is a cool idea! I could nitpick some of the glyph choices (e.g. U+233E ⌾ is really small and harder to read than @ and U+25CC ◌ looks like a circle and therefore the standard node type). But overall I like it!

I'm -0.25 on this.

I'm assuming https://abseil.io/ is part of the standard environment in oss-fuzz. Otherwise, we may want to vendor it or provide a script to download it or something.

I installed Dejavu Sans Mono from https://dejavu-fonts.github.io/ and it works great!

FWIW, this isn't rendering nicely with PuTTY on Windows 10. The U+25EF ◯ glyph is being truncated on the right side. I'm also seeing empty squares for U+233E ⌾ and other code points. Using Courier New as the terminal font. LANG=en_US.UTF-8 and TERM=xterm-256color, so Mercurial detects the encoding as UTF-8.

I'm assuming we don't need to bump the state version since the new state file format is still relatively new. But if we had shipped the new state file in a release, I would insist on bumping the state version any time new data is added to state.

This one worries me a bit because environment variable values can contain non-ASCII. However, the changed code only operates on HG_ variables and I think those variables are well-sanitized and should be ASCII safe.