Change Details

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 [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&action=history|history of Ernest Madu on Wikipedia]], and you'll see that [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820864133|revision 820864133]] has parent id 0 (with an "N" mark in the [[https://en.wikipedia.org/wiki/Special:Contributions/Andrewkazimi|user's contribs]]) instead of [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820863993|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. We should therefore add a new checkbox (perhaps unchecked by default) in the Special:Undelete interface saying "Reset parent ids" or something similar to mimic the old behavior. 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. Advantages of resetting parent ids: * Never makes revisions with broken parent revisions (T186280) * Always treats the oldest revision as a page creation * Allows fixing incorrect cases (e.g. [[https://en.wikipedia.org/wiki/Template_talk:Db-g1/Archive_1|Template talk:Db-g1/Archive 1]] on Wikipedia) Disadvantages: * May cause creation edits to suddenly become treated as non-creation edits if a deleted page has been recreated. * 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 * 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

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 [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&action=history|history of Ernest Madu on Wikipedia]], and you'll see that [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820864133|revision 820864133]] has parent id 0 (with an "N" mark in the [[https://en.wikipedia.org/wiki/Special:Contributions/Andrewkazimi|user's contribs]]) instead of [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820863993|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. We should therefore add a new checkbox (perhaps unchecked by default) in the Special:Undelete interface saying "Reset parent ids" or something similar to mimic the old behavior. 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. 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. Advantages of resetting parent ids: * Never makes revisions with broken parent revisions (T186280) * Always treats the oldest revision as a page creation * Allows fixing incorrect cases (e.g. [[https://en.wikipedia.org/wiki/Template_talk:Db-g1/Archive_1|Template talk:Db-g1/Archive 1]] on Wikipedia) Disadvantages: * May cause creation edits to suddenly become treated as non-creation edits if a deleted page has been recreated. * 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 * 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

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 [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&action=history|history of Ernest Madu on Wikipedia]], and you'll see that [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820864133|revision 820864133]] has parent id 0 (with an "N" mark in the [[https://en.wikipedia.org/wiki/Special:Contributions/Andrewkazimi|user's contribs]]) instead of [[https://en.wikipedia.org/w/index.php?title=Ernest_Madu&oldid=820863993|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. We should therefore add a new checkbox (perhaps unchecked by default) in the Special:Undelete interface saying "Reset parent ids" or something similar to mimic the old behavior. 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. 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. Advantages of resetting parent ids: * Never makes revisions with broken parent revisions (T186280) * Always treats the oldest revision as a page creation * Allows fixing incorrect cases (e.g. [[https://en.wikipedia.org/wiki/Template_talk:Db-g1/Archive_1|Template talk:Db-g1/Archive 1]] on Wikipedia) Disadvantages: * May cause creation edits to suddenly become treated as non-creation edits if a deleted page has been recreated. * 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 * 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