Bug filed here: https://bz.mercurial-scm.org/show_bug.cgi?id=6305

I'm not sure if the other op_state files need similar treatment. The fact that this catches a rebase mid operation makes me think this will cover everything.

Yeah, I remember hitting this too.

In D8524#134326, @sfink wrote:

In D8524#134322, @mharbison72 wrote:

The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.

I updated the commit message to "add .arcconfig to help messages and comments", which seems accurate.

The documentation updates look good to me, but there are still some code changes that were probably not intentional, and the commit message probably needs an update.

In D8948#134127, @marmoute wrote:

In D8948#134126, @mharbison72 wrote:

In D8948#134093, @marmoute wrote:

There are already a mercurial/rewriteutils.py files I think it should go there

So that causes a cycle:

--- c:/Users/Matt/hg/tests/test-check-module-imports.t
+++ c:/Users/Matt/hg/tests/test-check-module-imports.t.err
@@ -38,3 +38,5 @@
   > -X tests/test-imports-checker.t \
   > -X tests/test-verify-repo-operations.py \
   > | sed 's-\\-/-g' | "$PYTHON" "$import_checker" -
+  Import cycle: mercurial.cmdutil -> mercurial.rewriteutil -> mercurial.localrepo -> mercurial.extensions -> mercurial.cmdutil\r (esc)
+  [1]

That is really only used for type checking, so is that safe to move under if pycompat.TYPE_CHECKING: with the typing related imports, or is there another way to do this? Or should I just drop the type checking?

I am a bit confused about your question. What is "That" ?

In D8948#134093, @marmoute wrote:

There are already a mercurial/rewriteutils.py files I think it should go there

In D8948#134093, @marmoute wrote:

There are already a mercurial/rewriteutils.py files I think it should go there

phabsend test generation

phabsend test generation

phabsend test generation

phabsend test generation

In rHG5d09a120b4bec47e1c952d1457706b1d9b9f8405#57354, @martinvonz wrote:

I'm fine if other reviewers want to de-queue this patch, but maybe it's good to have it queued for now in case I don't end up with a good solution for the __index__.py-based fix soon.

I just wanted to point out that there's an __index__.py that gets generated in the py2exe case to handle some of this extension stuff when they aren't in the filesystem. I poked at this a bit 6 months ago or so, but was under the impression that PyOxidizer would eventually grow the capability to iterate over *.py resources, so didn't submit anything. Is that also your thinking, and this is a stopgap?

I'll try to take a closer look at this some time this weekend. In the meantime, can you explain more why it didn't work for you? There are tests that cover this feature, so I'm wondering if some coverage is missing.