With T183375, undeletion no longer sets the parent IDs for the undeleted revisions to the "expected" one given by the previous revision by ID (usually, but not always, also the previous revision by timestamp), but instead to the ar_parent_id values. For example, look at the history of Ernest Madu on Wikipedia, and you'll see that revision 820864133 has parent ID 0 (with an "N" mark in the user's contribs) instead of 820863993. While T183375 may have been a good idea, there are situations (such as selective undeletion or history splits) where it would be better to reset the parent IDs like they had always been.
Proposal
Add a new checkbox (unchecked by default) saying "Reset parent IDs" or something similar that, if checked, will fallback to the old behavior of resetting the parent revisions. If unchecked, ar_parent_id will be used as the rev_parent_id for the undeleted revisions, which is the current apparent behavior per T183375.
Alternative proposal
Always use the existing value of ar_parent_id unless it is "wrong" for any reason that can be automatically determined. If any of the following apply, the existing value will be ignored and the result of the getPreviousRevisionId function in RevisionStore.php will be used instead.
- The existing value is an unselected deleted revision for the same page title.
- The existing value is a revision, deleted or otherwise, from another different page title.
- The existing nonzero value is already used as the rev_parent_id for an earlier undeleted revision.
- The existing value is zero, but there are earlier selected revisions with the same ar_page_id.
- The existing value is a later selected revision, or a later live revision.
- The revision is the earliest one to be undeleted, and there are no earlier revisions in the page's live history (in this case, the rev_parent_id will be automatically set to zero).
Advantages (pros) of resetting parent IDs
- Never makes revisions with broken parent revisions (T186280 and T193211; useful when removing unwanted edits with selective undeletion, although using revision deletion would be even better)
- But don't use the checkbox when the only reason you are doing selective undeletion is that there are too many revisions to be undeleted at once, because it would cause the second disadvantage below
- Always treats the oldest revision as a page creation (useful when splitting histories)
- Allows fixing incorrect cases (e.g. Template talk:Db-g1/Archive 1 or Gema Switzerland on Wikipedia; usually caused by imports done in 2015 or earlier or undeletions of revisions deleted in pre-1.5 versions of MediaWiki; see also T38976)
- May be used to correct previous selective undeletions that should have been full ones (otherwise, we might get 2 revisions with the same parent revision)
- May also be used to fix some of the disadvantages below
Disadvantages (cons) of resetting parent IDs
- May cause creation edits to suddenly become treated as non-creation edits if a deleted page has been recreated
- To fix this, delete the page and then repeatedly undelete groups of revisions with the checkbox checked, starting from the latest group and then moving backward to earlier groups, where the groups consist of all revisions that originally belonged to one page ID
- May conversely cause non-creation edits to become unexpectedly treated as creation edits
- To fix this, delete the page and then undelete all of the revisions with the checkbox checked, trying repeatedly if necessary until it no longer gives an error (or just pick a small number n (e.g. 100) and then repeatedly undelete at most n revisions at a time with the checkbox checked, starting from the earliest n revisions, then the next n, etc., until there are no more revisions to be undeleted)
- May cause minor edits to no longer appear minor in terms of the red negative or green positive "change in size" number in the history
- To prevent this, always select the previous revision as well when selecting a minor revision
- May cause null revisions resulting from imports to have rev_parent_id set to the latest revision imported at the time instead of the immediately preceding revision by timestamp with the same text
- To fix this, delete the page, undelete all the non-imported revisions (including the null revision from the import) with the checkbox checked, and then undelete the imported revisions leaving the checkbox unchecked
Neutrality of resetting parent IDs
- Won't make a difference in most cases, where the page had just one deletion log entry excluding revision visibility changes
In general, to determine whether the proposed checkbox should be used or not, ask yourself: Does resetting the parent revisions improve the structure of the page's history?. If the answer is "yes", then use the checkbox; otherwise don't. Theoretically, the checkbox could allow the parent revision for a given revision to be changed to any desired revision with a smaller ID and earlier timestamp. But as long as the checkbox is not being used abusively, this shouldn't be a problem to worry about. Another suggestion is to never do "bad history merges", because bad things could happen with parent IDs (as the history of the page Mord Fustang on Wikipedia shows); in particular, when a redirect was deleted to make way for a move, make sure not to accidentally undelete the deleted redirect revisions.