@JJPMaster Well, consensus to request implementing this change. enwiki has no jurisdiction to compel any change to MediaWiki, and it's a bit irresponsible that the RfC implied it could. (That's on the nominator, not on you as closer, although I'd suggest a word other than "adopt" in the close for maximum clarity.) But as @Novem_Linguae said in the discussion, this should definitely be taken as a data point in favor of this change, and a pretty strong one at that.

Note: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#RfC:_Log_the_use_of_the_HistMerge_tool_at_both_the_merge__target_and_merge_source has been closed with consensus to implement this change.

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#RfC:_Log_the_use_of_the_HistMerge_tool_at_both_the_merge__target_and_merge_source

In T341760#9269957, @Pppery wrote:

A log entry at the _target was separately requested in T118132: Merging pages should add a log entry to the destination page. I personally don't see the point of any of these requests, though - history merging should if done properly be seamless and not need an annotation.

Change 967541 merged by jenkins-bot:

[mediawiki/core@master] Allow MergeHistory to split up joined revisions with same timestamp

https://gerrit.wikimedia.org/r/967541

Change 975391 merged by jenkins-bot:

[mediawiki/core@master] Fix testSourceUpdateWithRedirectSupport

https://gerrit.wikimedia.org/r/975391

Change 975391 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/core@master] Fix testSourceUpdateWithRedirectSupport

https://gerrit.wikimedia.org/r/975391

doesn't test what it is supposed to

So what should it test for and what is it testing now?

Changed my mind. This happened to me with undelete today too. This is best handled as part of the other ticket.

I do history-merging on enwiki (though not as often as previously) and the main reason I don't use Special:MergeHistory (except in unusual cases) is the lack of annotation. I think it should be annotated like any other edit/admin action that affects a page (yes when done cleanly the history should still seem natural, but sometimes history merges hard/impossible to do cleanly).

Change 967541 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/core@master] Allow MergeHistory to split up joined revisions with same timestamp

https://gerrit.wikimedia.org/r/967541

It seems like T38976: Diffs: Incorrect number of bytes added or removed because rev_parent_id is set to wrong revision might have multiple causes such as Special:Import, Special:MergeHistory, etc.

A log entry at the _target was separately requested in T118132: Merging pages should add a log entry to the destination page. I personally don't see the point of any of these requests, though - history merging should if done properly be seamless and not need an annotation.

If you know what you are doing you can do this via page moves. This is a major footgun so should be left to that emergent behavior not explicitly supported.

Does this really need to be done? Anyone who has mergehistory access almost always also has delete access so can delete the redirect themselves.

Related: T39465: Can't selectively undelete revisions with same timestamp

I'm sorry that I haven't handled this task. I recently returned from a long bout of unexpected inactivity, and while I plan to resume my contributions here on Phabricator its unfair to claim tasks that I might not work on when others may be interested in handling them. I'm removing myself as the assignee in a batch-action, but if someone feels that I really should be the one to handle this task feel free to re-assign me and I'll take a look.

Yeah I've thought something like this has been needed for a while. I'd been thinking of the idea of adding a log entry at the _target as well as the source, and that wouldn't go astray either, but that would probably not be so easy ...