Wikimedia Bugzilla is closed!

MergeHistory was enabled on three small projects, apparently without code review being done. We have not enabled MergeHistory on WMF projects in the past, for the following reasons:

* The write query changes an unlimited number of rows, and so can cause slave lag.
* The action is potentially extremely difficult to reverse, and so could cause a great deal of damage to a wiki if a sysop account were compromised.

Now, it is true that the delete/undelete method for merging history has the same two caveats, and so Special:MergeHistory is basically a nicer frontend for the same feature. But providing a simplified frontend for a feature is a kind of promotion, and it would be best if the backend were sensible before we did such promotion.

Note that the fact that undeletion can merge history was accidental. The feature was certainly not reviewed for the potential of malicious or accidental damage before it was deployed, because the first people to discover it were users, not developers.

I suggest:
* Deferring and throttling history merges, like what we do for user renames. Or alternatively, limiting history merges to pages with a few thousand revisions.
* Adding an "unmerge" feature, accessible from a link on the merge log line. Perhaps this could work by traversal of rev_parent_id starting from a rev_id stored in log_params.

Once this is done, the mergehistory right can be given to sysops by default in the MW core and on all WMF wikis, and then the misfeature allowing Special:Undelete to merge histories can be removed.