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.

In D8454#126891, @marmoute wrote:

Now that I see it, I think we shoul dinclude all heads because the mssage might be confusing "multiple heads: one-hash"

In D8454#126862, @marmoute wrote:

In D8454#126857, @mharbison72 wrote:

Gentle ping on this. I think I addressed the concerns raised, and didn't want it overlooked for the release if it's still in the changes requested state.

Did not we want to update the message ?

Gentle ping on this. I think I addressed the concerns raised, and didn't want it overlooked for the release if it's still in the changes requested state.

I'm not real familiar with how rebase works, and seems like it's pretty intricate code. I'd also feel better if there were tests for the original commit referenced. But it's very unlikely that I'll have any time before the weekend to look at this again, so I thought I'd send it out now. Maybe it's narrow enough or maybe somebody can backfill the tests, and we can avoid a known data shredder in the next release.

I'm trying to build this with PyOxidizer and get an error after upgrading to v0.7.0. I wonder if some of the references in rust/hgcli/Cargo.lock need to be updated from 0.7.0-pre. Here's the command output:

This may not be a big deal, and I'm not sure that this patch is the cause. When I built the py2 installer with py -3 contrib\packaging\packaging.py wix --python C:\Python2717\python.exe, I got a 25K hg.exe in the dist directory with all of the installers that had a mod time 1 minute before the installer. I don't remember seeing this when I was building installers at the end of January. (It also has screwy output, but that's a different issue)

In D8457#126469, @marmoute wrote:

For demo purpose only → getting it out of review. Put it back in review if I am wrong.

In D8345#126157, @marmoute wrote:

@mharbison72 @indygreg, IIRC Matt is saying this is the wrong fix. What's the status of this?

In D6846#126171, @marmoute wrote:

So as I understand this is not ready to land and should be moved to change-requested (or change planned), right ?

s/requirements is not/requirement is now/ in the summary, but otherwise LGTM

I think it might make sense to make some of these messages note() or debug(), but this is still an improvement.

In D8439#125864, @mharbison72 wrote:

This helps it get further, but then it dies with messages like:

find: cycle detected for /lib/secure/32/
find: cycle detected for /lib/crypto/32/
find: cycle detected for /lib/32/
...
install: hg-ssh.8 was not found anywhere!
find: cycle detected for /lib/secure/32/
find: cycle detected for /lib/crypto/32/
find: cycle detected for /lib/32/
...
install: hgrc.5 was not found anywhere!
...

This helps it get further, but then it dies with messages like:

This was to generate tests.

This was to generate tests.