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?
Sun, May 31
Sat, May 30
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).
Well, I attempted to rewrite @. But somehow the empty changeset got published before that push completed. So it is forever part of history now :/
It looks like hg phabread | hg import - produced an empty changeset, which I accidentally pushed. I have since rewritten @ on hg-committed to remove the empty changeset. This differential revision should be reopened (which I cannot do since I don't own it).