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.
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, 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:
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.
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.
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 inof page Clemson Tigers football. There is an example with 5 incoming pages in 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.
Administrators can use a special page, Special:MergeHistory, to perform history merges. It differs from the manual methods, as follows:
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.
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
(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:
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:
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:
"WP:PV" redirects here. For pageviews, see Wikipedia:Pageview statistics.
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:
In this case, the time periods of the two series of edits will overlap.
If someone then page-history merges pages A and B using the method described above, the result will sequence the versions of A and B 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).
The MediaWiki software does not allow page history to be publicly archived at a page title that does not host a live page or redirect. Therefore, if two pages with parallel histories are merged but it is undesirable to keep a redirect from the deprecated page title to the destination page title, the old page history needs to move. This is sometimes done by moving the page history to a subpage of the talk page of the destination page. An example can be found at Talk:Compilation of Final Fantasy VII#Old page history. Use the ((Parallel version)) template for tagging parallel versions found on talk pages.
Also, if page A is to be history-merged into page B, before the process, make sure that there are no deleted edits in page B, as then deleting B will shuffle the deleted and non-deleted edits attached to the page together. The deleted history should first be rescued from under B by some process such as this: Move B to some other name, say B_zxcvbnm (without making a redirect). Undelete B. Move B to some other name, say B/old_version . If necessary, re-delete B/old_version . Move B_zxcvbnm back to B (without making a redirect).
Likewise, if a page must be deleted and then partly undeleted for a history-split, first check in case it is sitting over a deleted parallel history.
Over time, articles may change from one underlying topic to a completely separate topic. Normally this should be accomplished through moves and disambiguation pages. However, if a user is unfamiliar with those processes they may simply change the topic of an article (overwriting the old) and continue editing. If this is not caught immediately it is very easy for the new topic to build up a substantial edit history of its own. Admins can use the following steps to fix this problem and maintain separate histories for the separate topics:
In most cases, you will be moving all non-redirect versions of one page into the history of another and leaving a redirect. Please keep the following situations in mind when deciding what to do with the redirect:
If page X is transcluded in page Y, and page X is marked to be the recipient in a history-merge, then page X and page Y will both appear in Category:Candidates for history merging, and both pages will display the request to perform a history-merge. An admin should not try to perform a history-merge on page Y, but only on page X. This is most likely to happen if page X is a template, but it may happen to any page that is transcluded. To avoid this,
((history merge)) should be placed in
<noinclude> tags on page X.
If a history merge should not have been performed, then it may be undone. Note, however, that it can be quite tedious, especially if the article has a very long history. The following procedure is listed:
An example of a successful history merge and undo is available at User:King of Hearts/Sandbox/6 (the A article) and User:King of Hearts/Sandbox/7 (the B article).
See also: Wikipedia:History merging/Old bugs
When a page is moved, two edits are made, with consecutively numbered revision IDs and identical timestamps & edit summaries. In edit histories, the timestamps are usually shown to the minute (
17:47, 21 January 2008), unless the ISO 8601 date format preference is set; however, in the database they are recorded to the second, e.g.:
|difference in bytes and page content
|moved Élie, duc Decazes to
|0 — an edit is made on the target documenting the move in the edit summary, with no difference in page content
|moved Élie, duc Decazes to
|Élie, duc Decazes
| -8,264 — the source page's text was replaced with
#REDIRECT Élie Decazes, Duc Decazes
Live edits are uniquely identified by their revision ID numbers, but deleted edits are referenced by their timestamps. As long as these two revisions are located on different titles, this isn't a problem. However, if the two edits are inadvertently histmerged to the same page, and then temporarily deleted, it is impossible to restore one of these edits without restoring both of them, because they share the identical timestamp which identifies which edit to restore. Thus care should be taken not to move or histmerge a page-move generated
#REDIRECT edit off of the page it was made on.
#REDIRECTs should stay on the page on which they were created, either as live or deleted edits.
These can, however, theoretically be separated using Special:MergeHistory, but in practice this is a particularly inelegant and tedious method for anything other than what it was designed for (i.e. history-merging).
Page moves and deletions are generally reflected on Wikidata as soon as they happen. After performing a history merge, it is a good idea to check your Wikidata contribs (convenience link) and restore pages to their previous state if necessary.