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).
No, but I think those two places should be able to accept an overlayworkingctx, so it might be better to leave them unchanged for now and to switch them directly to use wctx.mergestate() once we have a wctx passed in here.
Yes. I guess I'd rather have the pattern wctx.mergestate() indicate that it works with either a workingctx or a overlayworkingctx, while direct access to mergestate.read() indicates that we care about the actual working copy.
Is there any reason to distinct the two ? From afar, it would be better for the mergestate module to become an implementation details and every access to happen throught the context for consistency.
Do you have concrêt example where distincting the two seems better ?
Okay, now localrepo correctly uses the same context across whole operations. This almost certainly avoids some bugs, given that committing a memctx was (surprise!) reading the mergestate from disk.