Wikipedia:History merging
In the early days of Wikipedia, renamings took place manually, using cut and paste, before the move page function was enabled for non-administrators in August 2002.
Cut-and-paste moves still occur today because of unfamiliarity with the move function, unawareness that attribution is necessary, or when the move function fails (e.g., because the target has history) and people don't know to use the Requested moves forum to start a move request.
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 highly undesirable, because we need to keep the history with the content for copyright reasons. (See Wikipedia:Copying within Wikipedia.)
In some circumstances, administrators can fix this by merging page histories, using the procedure given below.
When to request a histmerge
A history merge is required for attribution purposes, as attribution is lost during a cut/paste page move where there are multiple editors at the old page. In the image shown, it appears as if the user Thegreatrebellion had created the entirety of the added text at Syed Saddiq, when the reality is that there were contributions from over 200 editors at the previous page name of Syed Saddiq Syed Abdul Rahman.
While this is not an exhaustive list, any pages meeting the below criteria may be eligible for a histmerge:
- There are several editors in the page history at the original location
- The editor who blanked and/or redirected the page used an edit summary such as "move to <new page name>"
- The new page was originally a redirect and was overwritten by the "new" article
When not to request a histmerge
New editors are often unaware of the ability to move pages (or are unable because of new-account restrictions), and will thus copy/paste a draft they have been working on into the article space. Similarly, a New Page Reviewer may move a new article to the Draft space and the original editor will simply recreate it in the Article space. In both of these situations, if the original editor is the only one that has contributed content to the pages, a history merge is not necessary because there are no attribution issues (only one editor has written all of the content).
If trivial edits are made by other editors, such as maintenance tags or categorisation, and these edits are not transferred over by the primary content author, a history merge is not needed.
Instructions for tagging a page for history merging
- Place {{History merge|NAME OF PAGE THE ARTICLE WAS CUT FROM}} at the new location, where the pasting was done. The page will appear in the hidden category Candidates for history merging.
- Consider notifying the user of the issue on their talk page, perhaps using {{subst:uw-c&pmove}}.
In cases where additional edits were made to the original version after the copy-and-paste and which the additional edits can all be safely discarded (e.g. WP:WPAFC-related templates, edits which were reverted, etc.), place {{History merge|NAME OF PAGE THE ARTICLE WAS CUT FROM|reason=|details=}} at the new location as described above. Fill in the two parameters as needed for this particular situation (see {{history merge}} for an example).
If there are no changes since the copied-from revision in either the original page or the pasted-to page, consider tagging the pasted page for temporary deletion using {{db-copypaste}} (see WP:Speedy deletion#G6), and then do a proper page move. Special:ComparePages or a similar tool should be used to verify that no changes have been made.
In more complex cases (explained below), please leave a description of the problem at Wikipedia:Requests for history merge.
Parallel versions
The ideal situation for a history merge is when an editor copies and pastes all content from one page to a brand new page, and then the old page does not receive any more edits. In other words, where the first page's history stops, the second page's history begins, and there are no overlapping diffs.
Users sometimes send in an ill-advised history-merge request after the two pages involved have been text-merged. If the two pages have separate origins and simultaneous separate parallel histories before they were text-merged, they should not be history-merged, as that would shuffle the parallel editing histories together in one list and make a mess. There is an example in this edit of page Clemson Tigers football. There is an example with 5 incoming pages in this edit of page Wikipedia talk:WikiProject Emo. The best thing to do would be to use the {{Copied}} template and place it on the source and/or destination's talk page, in order to meet the copyright attribution requirements of Wikipedia:Copying within Wikipedia.
Repair process (for admins)
Using the MergeHistory special page
Administrators can use a special page, Special:MergeHistory, to perform history merges. It differs from the manual methods, as follows:
- It automatically detects the latest version of the source page which is older than the oldest version of the target page, and won't allow the user to move later revisions. This feature is good if the source page eventually became something else, but can be bad if the target page had started out as a redirect to the source. When a redirect is blocking a full MergeHistory merge, the redirect and any older edits will need to be either deleted or merged to another redirect. Deletion and restoration of pages with lengthy edit histories is very time- and resource-intensive, and administrators are not allowed to delete pages with more than 5000 edits in their history. An easier option in these cases may be to history-merge the redirect and any earlier history to another redirect that was created later. See § Clearing away merge-blocking redirects.
- The user can, however, tell it to only move earlier revisions than that – it is possible to select the latest revision it should move.
- It doesn't mix deleted and non-deleted versions of the target page.
- It retains any protection the target page may have.
- It doesn't create a new revision of the old page.
- If the user moves all non-deleted revisions of the source, a hard redirect is automatically created. This can't be overridden.
- The logs for this action aren't in the move log - they're in a separate log.
Clearing away merge-blocking redirects
- To clear a blocking redirect by deleting it:
- Check for deleted history at the target, and take note of all deleted edits there
- WARNING: Beware the co-mingled revisions issue. WORKAROUND:
- Move the page to draft: namespace before deleting it, with the rationale: "history-merging process".
- Restore the oldest (redirect) revision(s) – these would have been deleted by a regular move when it "moved over the redirect"
- Move the page with the oldest (redirect) revision(s) back to mainspace, then delete it (adding to the already existing deleted revisions)
- Restore the remaining history and move it back to mainspace
- WARNING: Beware the co-mingled revisions issue. WORKAROUND:
- Delete the target page with the rationale "setting up for a history merge"
- Restore all but the previously deleted edits and the oldest (redirect) revision(s) – these would have been deleted by a regular move when it "moved over the redirect"
- Deletion and restoration operations often time out with errors on pages with long edit histories. Simply try the delete or restore again; it virtually always succeeds on the second try
- Now MergeHistory can do the merge; this technique avoids making a new edit that needs to be reverted, which happens when the source is moved to the target
- Check for deleted history at the target, and take note of all deleted edits there
- To clear a blocking redirect by history-merging it:
- Find other redirects to the target page using Special:WhatLinksHere, while hiding links and transclusions: What redirects here Example: Pages that redirect to "Yasser Arafat International Airport"
- Find an appropriate redirect, whose oldest revision (creation date) is newer than the most recent revision of the redirect history that needs to be cleared
- Merge the blocking redirect history to that redirect. Example: Special:PageHistory/Gaza Airport. The April and July 2005 revisions were merged here from Yasser Arafat International Airport (log)
- Now MergeHistory can do the merge; this technique avoids making a new edit that needs to be reverted, which happens when the source is moved to the target
- Instead of finding redirects, you can make a temporary page (for example, in draftspace), merge the blocking redirect history there, and then delete the temporary page when you're done.
Manual process
Warning: this procedure may only be undone by spending quite silly amounts of time. To undo a merge, see below. Do not do this if you're not sure what you're doing.
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 process is as follows:
- Move Alabama/History to History of Alabama, using the move tool. The admin approves deletion of History of Alabama to allow the move. (Now the old versions are the whole of the new title's history.)
- Undelete the History of Alabama article, by
- Viewing the Page history,
- 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
- Clicking "Page history" on History of Alabama.
- Make a hard reload (Shift+Control+R in Mozilla or Opera, Ctrl+F5 in Internet Explorer, and Ctrl+R in Firefox) to see an up-to-date history reflecting the undeletion.1
- Reverting to the last pre-move version.
Merging page histories of pages with many revisions
Suppose that the page History of Alabama had too many revisions to be deleted or deleting it may cause other disruption. The following procedure can be used to merge page histories in this situation:
- Move History of Alabama to Alabama/History with a move summary like "history merge, will be back at correct title soon". Answer yes when asked to delete the Alabama/History page.
- Undelete the revisions of Alabama/History containing the page history.
- Move Alabama/History back to History of Alabama.
- If needed, undelete the remaining revisions at Alabama/History.
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.
To select more than one revision for undeletion, click on the tick box of the first revision to be undeleted, then shift-click on the last revision to be undeleted. Every intermediate revision will then be selected.
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".
- The versions of "Japan Self-Defense Forces" at Military of Japan are moved to Japan Self-Defense Forces, using the normal page-move function. For this to happen, Japan Self-Defense Forces must be deleted, although this can be done as part of the move.
- Undeletion of Japan Self-Defense Forces restores the rest of the versions of that article to its history.1
- 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 3 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.1