This is now much closer! I'm down to a handful of failures, all like this:

ha!

Breaks many tests for status code, sadly.

Doesn't this break HGPLAIN=1 hg files -T'{path|short}\n' or similar?

I can see some room for improvement in the log message, but it's good enough IMO and I can't really figure out a better wording.

I don't see the changes as having been folded: there are changes in 8578 that aren't here. Missed a phabsend maybe?

Yeah, I'm happy to reorder patches, this is still a bit "work-in-progress unfortunately.

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'm okay with the series, but I'm a little hesitant to put something this big on stable. Can you sway me one way or the other?

This patch is contentious, but I'm a little unclear why. Summarizing so everyone at least parses my thoughts roughly the way I mean: mandatory parts mean "fail if you can't process this part." It seems basically reasonable to me that a client can choose to ignore (perhaps through ignorance) obsolete markers and it'll be potentially confusing, but not /wrong/ in that they'll have the changesets they expected, but also didn't lose some the server thought they would. It feels like a bug if a client requests obsmarkers and then discards them? But in the case of any kind of pre-computed bundle it's a little trickier because if the server (as an optimization, in this case) emits obsmarkers that the client didn't request, it could break old clients.

I assume this fixed ... something? Is there any test you could add to one of the test-git*.t tests that would demonstrate that?

Seems fine to me, but I want one of @martinvonz or @marmoute to look at this.

For anyone curious what's left, the test currently fails like this: