Wikipedia:History merging
- Non-admins, or admins who would rather someone else perform this slightly complex task, can list such article pairs at Wikipedia:Cut and paste move repair holding pen, where they will be attended to by an admin specializing in this procedure.
- To request a merger of duplicate articles, see Wikipedia:Duplicate articles.
In the early days of Wikipedia, renamings took place manually, using cut and paste, before the move page function was created by our hard-working developers.
Now, cut-and-paste moves are usually done by people who are not aware of that function, or when the move function fails (e.g. because the target has history), and people don't know to use Wikipedia:Requested moves (WP:RM) to ask for help from an admin.
When a cut-and-paste move is done, the page history of an article or talk page can be split among two or more different pages. This is Very Bad, because we need to keep the history with the content for copyright reasons.
In some circumstances, administrators are able to fix this by merging page histories, using the procedure given below.
Repair process
Warning: this procedure may only be undone by spending quite silly amounts of time: to undo a merge, every single version has to be manually reassigned to its respective former page. Do not do this if you're not sure what you're doing.
Note: As of September, 2005, due to some minor bugs in the Mediawiki code, article histories may seem to contain anomalies after performing some of the procedures listed below. They are not actual data-base errors, the underlying data is correct; they are just problems with the information displayed. See #Notes for information about these seeming anomalies, and how to deal with them.
An easy case
The following procedure merges the page histories in the case of a hypothetical example:
Suppose Alabama/History (old title) was the only article on that subject, and that the article developed in the course of a number of edits, until a decision that History of Alabama (new title) was a better style of name for the article. Suppose further that for whatever reason, the contents of the old article were
- cut from the old article,
- replaced in it with a redirect to the new title, and
- pasted into a newly created article bearing the new title.
(That is, the move tool was not available or not used, to simultaneously transfer the Wiki text and the history of edits to the new title.) And suppose this replacement (new-title) article develops further and reflects the new history of these further edits. Our goal is to graft the (old) edit history from Alabama/History (article with old title) onto the new history in History of Alabama (article with new title) where those partial histories can complement each other. The admin:
- Deletes History of Alabama, with comment deleting to merge page histories - back soon. (Now the new title has no versions in its history.)
- Moves Alabama/History to History of Alabama, using the move tool. (Now the old versions are the whole of the new title's history.)
- Undeletes the History of Alabama article, by
- Viewing the Page history, [1]
- Linking via "View or restore ... deleted edits?", and
- Clicking on "Restore!". (Now the new title's history has both the old and new versions, including an extra copy of the most recent version of Alabama/History, created by the move tool.)
- At this stage, History of Alabama will only show the text "#redirect History of Alabama" (assuming a redirect was the most recent version of Alabama/History - the History of Alabama page will now be showing whatever the most recent version of Alabama/History was). The last step is to revert to the last version of History of Alabama from before the move, by
- Linking via "Page history" on History of Alabama.
- Make a hard reload (Shift+Control+R in Mozilla and Ctrl + F5 in Internet Explorer), in order to see an up-to-date history reflecting the undeletion. [2]
- Selecting, editing (ignore the warning message about "WARNING: You are editing an out-of-date revision"), and saving the last pre-move version.
Notes
Note 1: ^
As of September, 2005, with MediaWiki 1.6alpha, the following peculiarity will likely be observed: after a successful undeletion, article histories may seem to either:
- Be missing the recently-restored versions, or
- Show the complete original history after a deletion/partial-restoration cycle, including versions which are actually still deleted.
These errors persist even if the browser's "Refresh" button is clicked. These do not seem to be actual data-base errors, and the underlying data is correct; they are just problems with the information displayed. Note that there seems to be no consistency as to which (if either) of these bugs will appear - expect to see either, or neither.
To see the correct, current, history of the article, select a different history length, e.g. "last 20" or "last 100", instead of the default 50. (Note that this trick only works once; if you do another restore, and the history is messed up again, you will need to select a different, previously unused length, to see the correct, current, history.)
Also, making an edit on the page just moved will force the correct history to be shown, so if you have to perform an edit on the target page for some other reasons (e.g. to restore the most recent version, step 4.3 above), this will make the correct history appear. Alternatively, if you don't want to leave things so that a naive user will be confused, make a gratuitous edit to the page, which will update the history.
Note 2:
Previous versions of the Wikimedia software displayed other, similar issues:
- The success of the undeletion may be announced, but its results not be observable for a while, until the slave servers catch up to the master.
- The merged history may have all the versions of the two formerly separate articles, but without the most recent being shown at the top of the history list, and without the most recently edited version being delivered by the server, until a further edit is made to the article.
- It sometimes happens that viewing the history in step 3.1 shows the history of the just deleted page, not the history of the page just moved.
These bugs do not seem to be happening any more, but it's worth keeping an eye out for them.
A more complex case
Sometimes, after a cut-and-paste move is performed, the article at the old title is then edited for some other purpose (e.g. turning it into a disambiguation page). That causes the article now at NewTitle to have part of its history there, and part at OldTitle, but the history at OldTitle also contains the history of NewMeaning. Use of the selective deletion function allows these to be repaired as well.
An example of this was Military of Japan; the original was moved to Japan Self-Defense Forces with a cut-and-paste move, and the article Military of Japan was then turned into a disambiguation page. This was repaired with the following procedure:
- Military of Japan is deleted.
- Selective undelete is used to undelete only those versions of Military of Japan which belonged to "Japan Self-Defense Forces".
- Japan Self-Defense Forces is deleted. [3]
- The versions of "Japan Self-Defense Forces" at Military of Japan are moved to Japan Self-Defense Forces, using the normal page-move function.
- Undeletion of Japan Self-Defense Forces restores the rest of the versions of that article to its history. [4]
- However, the most recent version in the history of Japan Self-Defense Forces is now the most recent version of the old history from Military of Japan (it's a copy of that version, created by the page-move function). So, go into the history of Japan Self-Defense Forces, select the next-most-recent version, click on it, and when it appears, click on "Edit this page", ignore the "WARNING: You are editing an out-of-date revision" message, type something suitable (e.g. "Restoring most recent version after merging histories") in the edit summary, and hit "Save page". That article is now restored to its condition prior to this procedure, and now also has its complete history.
- Step 4 above (the move) will have left a history containing just a redirect at Military of Japan. Delete the redirect.
- Undeletion of all the other versions of Military of Japan restores the more recent history of that article; no additional steps are needed, as the most recent version should now be the current version. [5]
A troublesome case
However, the examples just described only work well if the two pieces of the history of one 'article' are disjoint; i.e. one ends before the other begins. These procedures are inadequate if this condition does not apply, e.g. if the copy of the article at the old title has been edited after the pasting of its contents into the new title. For example, it is not uncommon for:
- an article at (old) page A to be cut and pasted into (new) page B, and
- page A to later be reverted to an article on the same topic, with a sequence of edits there as well.
In this case, the time periods of the two series of edits will overlap.
The procedure above performs a page-history merge that (sooner or later) sequences the versions strictly by time, with the result that various versions of A will be interleaved between versions in the page history of page B (and/or vice-versa). Inspecting this merged history without means of distinguishing between the two overlapping progressions (since nothing in this history indicates which version belongs to which sequence) invites severe confusion.
An appropriate procedure for such a case is to forego the history merge, and instead handle the situation much like a normal merge; put a note pointing to the other version of the page on the article's talk page. If it is inappropriate to leave the second copy in the main article space, you can archive the duplicate page to Talk: space (i.e. by moving it to some suitable title, such as Talk:RandomArticle/OldVersion).