Maybe another option is to allow multiple -d arguments for this case? Something like hg rebase -r C -d B -d D. I haven't thought through BC, but I think that's what I'd prefer if we were writing rebase from scratch. I know we can't support hg rebase -r C -d 'B + D' for backward-compatibility reasons (because we already support that -- it rebases to the highest revnum in the set).

This is not meant for review; I'm sending it now in case it'll be useful for @durin42's work on merge-diffs. I also included the rest of the stack to explain why I wrote the code.

In D8552#127900, @durin42 wrote:

In D8552#127895, @martinvonz wrote:

I think I'd prefer to leave code that doesn't use overlayworkingctx unchanged. I don't see any reason to get the merge state from the context if we know that the context is a regular workingctx.

I'd rather it was globally-consistent that if you need a mergestate, you load it via a context, so that more code will implicitly be right for in-memory operations.

It looks like the latter two hunks in this file will need to be able to read the merge state from an overlayworkingctx. Maybe that's coming in a later patch, but I think it would be easier to follow if this code was changed only then (very much related to my comment on an earlier patch).

I think I'd prefer to leave code that doesn't use overlayworkingctx unchanged. I don't see any reason to get the merge state from the context if we know that the context is a regular workingctx.

Also update the release notes to mention the API change?

Thanks for the quick fix and the added test case!

Mention API change in relnotes/next?

Looking forward to using this!

I'm queuing this series. Thanks for all your work on packaging!

Why do we even give the choice between 3.7 and 3.8? Just because it was easy to do so anyway? Since the Python runtime is embedded, there's very little reason to try to match a system Python or something, right? To be clear, I don't have an issue with allowing it; I was just surprised by it and wanted to make sure I understand it correctly.

In D8244#126461, @marmoute wrote:

Gentle ping on this. This is still ready for review.

I thought I already had abandoned this, but apparently not :)

In D8463#126264, @marmoute wrote:

Okay. I am still a bit lost about what do you have in mind ? If the user do not act of the last-message.txt but move to something else, it seems reasonable that it get cleanup, right?

In D8463#126262, @marmoute wrote:

I don't understand wer you are going with this mention of "other operation". But I don't think they loose it. It only get overwritten when a new one is written.

In D8463#126258, @marmoute wrote:

Manual copy pasting is not necessary, hg commit --logfile .hg/last-message.txt can be used to reuse that message and hg commit --logfile .hg/last-message.txt --edit can be used to re-use and edit the message.
I would recommand that instead.

In D8398#125451, @martinvonz wrote:

In D8398#125450, @joerg.sonnenberger wrote:

Think about any attempt to localize the error message.

Would have helped to put that in the commit message. So the pycompat.bytestr() call is unrelated and not needed, right?

In D8398#125450, @joerg.sonnenberger wrote:

Think about any attempt to localize the error message.

What was broken before? The test case still seems to pass for me if I undo the code change.

In D8376#125174, @pulkit wrote:

In D8376#125173, @marmoute wrote:

I would prefer you wait for planned change to land before you do further change to the file. The coming changes fixes bug and I rather not have to fix too many conflict while doing so.

I already pushed them, I will resolve conflicts on those couple of patches and update them on heptapod.

This one is trivial to move ahead of the other two patches so I'll queue it and fix any conflicts in flight.

Heads up that we ran into a fun bug that was probably caused by this patch. I think what happened was this: