Wikipedia talk:History merging/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

Dealing with the Troublesome Cases

Wikipedia:How to fix cut and paste moves#A troublesome case [My link error now fixed by Jerzy(t) 03:21, 2004 Oct 24 (UTC)] endorses merging two pages' histories when one has the history before the cut and past move, and one the history after it. But it throws up its hands at keeping the whole history when a history merge would result in interleaving the edits of the two starting pages. I have done a number of the latter fixes (i assume i'll be able to dig up examples), using an approach that enables users to deduce which file-comparisons show differences that only appear to reflect what changes the newer version introduced, and (more importantly) which comparisons to use to find the changes introduced in any real edit. The method is to save the text of both histories, before doing the merge, and instruct users to find the two adjacent time stamps in one of those saved histories, and to use the "live" merged history to compare those two versions (rather than blindly assuming two adjacent versions, in the live history, were consecutive versions of the same page and thus have the relationship of being the before and after states of an edit).

IMO it is more in the spirit of WP's overall practice to keep the evidence that makes the authorship verifiable, rather than instruct admins to make a potentially subjective judgement about " principle principal authors", and then destroy the evidence.

[Fixed my misspell. --Jerzy(t) 03:21, 2004 Oct 24 (UTC)]
Rereading, i see that my claim of "destroy[ing] the evidence with the currently recommended procedure is mistaken. I should have described it as
  • (in the case where the editor is more conscientious than the instructions suggest, and puts into the edit summary a reference to the note on the talk page) "discouraging access to the evidence" (by leaving half of it awkward and confusing to find, obscured behind at least one redirect and Move's non-documentation in pages' histories of what their sometimes multiple former names were), and
  • (failing that diligence) concealing the evidence, at least from those who don't look at the talk page.
--Jerzy(t) 03:21, 2004 Oct 24 (UTC)


I've been hesitant to correct the hopelessness of that writer, in case they thought of the same approach, and simply regarded it as too confusing to teach, and preferred hiding the truth over giving complicated reasons for not using this approach. But even if that's the case, IMO on reflection, we deserve not to be lied to about the possibility, and the passage should be reworded, even if we want to do something in the range between forbidding the use of my approach and offering no help to those who think they might be able to master it.
--Jerzy(t) 23:30, 2004 Oct 20 (UTC)

Interesting idea, but I think it'd still be very confusing - what if someone checks history without first checking talk? Martin 00:55, 21 Oct 2004 (UTC)

Since

  1. users who don't look at the talk page (and find the pre-merge histories) would also never have seen the list of principal authors (and would have misunderstood some of them as having had no participation), and
  2. those who do look at it will see the pre-merge histories and come out with more information,

your concern is when

  • an article's editor, who merges & saves pre-merge histories, would otherwise instead (perhaps in response to instructions that get improved next week) have done both the note and the list of principal authors (neither of which, BTW, i've never noticed an example of -- just FWIW, since any individual's sample is small and perhaps relevantly biased), and
  • that page's user doesn't think to check the talk page.

It would seem that such an occasion for harm would be easily and adequately remedied by something that IMO falls far short of a SMOP: adding a line of text to the code for presenting page-histories that says

Caution: "(last)" comparisons do not necessarily compare the pre-edit and post-edit states of the same page, for pages where page-histories have been merged. Consult the talk page for information on any revevant merges.

(Less than a SMOP: the testing should be just prudent insurance against clerical screwups, rather against "real" programming errors.)
--Jerzy(t) 03:21, 2004 Oct 24 (UTC)

Not very far off topic: Even if GFDL is legally airtight in this respect, and whether or not the pre-merge histories on the talk page are endorsed, the moral authority of MediaWiki projects would be significantly improved by adding, in the place discussed,
Various forms of cut-and-paste editing and history merges interfere with the accuracy, thoroughness, and transparency of the page histories' automated record of authorship, as discussed at [appropriate Meta address].
--Jerzy(t) 12:03, 2004 Oct 24 (UTC)

Please help with Talk:Hubbert peak

I deleted the Hubert peak redirect page and then moved Hubbert Peak to Hubbert peak. It said the talk page could not be moved because there was already a talk page with a history. So I looked at this page, where it says:

The admin:
  1. Deletes History of Alabama, with comment deleting to merge page histories - back soon. (Now the new article has no text and no history.)
  2. Moves Alabama/History to History of Alabama, using the move tool (giving the new title the old history and the old versions).
  3. Undeletes the History of Alabama article.
  4. Goes to the page history of History of Alabama. (Now it is a self-redirect.)
  5. Presses Ctrl + F5 (on Internet Explorer, or whatever action forces a hard refresh with the browser in use).
  6. Undeletes the deleted versions of History of Alabama, putting back in place the new versions and history.

I tried to follow this procedure. It does not appear to have worked. The assumption that normal humans use Internet Explorer didn't help. Like all normal people, I'm using Linux. I used control-shift-R in step 5. How is this process supposed to work? Michael Hardy 00:49, 21 Nov 2004 (UTC)

Just as well it didn't, and that you seem to have omitted the undelete step in the confusion, as this is exactly the kind of situation that the article warns against: the two versions Hubbert peak and Hubbert Peak (Hubert peak turns out to be a typo for Hubbert peak) coexisted, each accumulating revisions, from April 5 to June 22, and (without careful inspection) there is no certainty that the individual edits could havee been deciphered even in theory, as the GDFL anticipates, i you'd succeeded, but virtual certainty that no one would go to the trouble. The 41 currently deleted revisions are recoverable, and the failure of the effort to dump them in will make feasible a workaround-guide for viewing the diffs within the jumble that will result.
Repair involving both articles and talks in progress today; others please forbear. --Jerzy(t) 18:59, 2004 Nov 22 (UTC)
Oh, yeah: Done. --Jerzy(t) 04:09, 2004 Nov 23 (UTC)

Obsolete warning?

This warning:

Warning: this procedure may only be undone by a developer, 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.

is probably now obsolete, because with selective undelete, an admin can in fact undo a merge (provided you figure out which versions belong in which history). Simply i) delete the page, ii) undelete only the versions which belong to history A, iii) move that article elsewhere, iv) undelete the rest of the versions, which belong to B.

I will delete the words "a developer", leaving the warning correct, but making plain that doing a merge can have painful results. Noel (talk) 13:56, 13 Mar 2005 (UTC)

Un-merging history

To fix a copy move, it is sometimes necessary to move some revisions of a page to a new location, while leaving the others. For example, suppose someone copies Marking out to Marking out (professional wrestling), then writes a different article at Marking out, with many edits. To fix the move, I need to get the original history, before the copy-move, to Marking out (professional wrestling) and leave behind the newer history.

I take it you can separate revisions in the history by the following process

  1. Delete the page
  2. Undelete the revisions you want to be elsewhere
  3. Move the page
  4. Undelete the rest of the revisions

But I've never done it, and this page doesn't currently address the issue. So, are the above four steps right? dbenbenn | talk 18:48, 25 Mar 2005 (UTC)

Yes, with the new selective undelete, you can do this kind of thing (see my comments in the section immediately above) - I do this now when I'm doing cut-n-paste move repairs to remove the redirects from the history. This page hasn't been fully updated to reflect that you can now do this kind of thing - it used to take a developer to untangle merged histories. (As I mentioned above, I did fix the text where it used to say that it took a developer to un-merge histories.) Noel (talk) 14:14, 28 Mar 2005 (UTC)
I have now written a new section which explains how to use selective undelete to separate one history into two (and join one onto a second, when an article was cut-and-paste moved). Noel (talk) 19:26, 28 September 2005 (UTC)

template:disambig and template:nocatdab

A while ago, someone moved {{disambig}} to {{nocatdab}}, and he tried to revert the move by cutting and pasting. I'd use the normal method in reverting cut-and-paste moves, but {{disambig}} is used by over 30,000 pages, and I don't want to mess up 30,000 at once. I think that an experienced administrator may be required to fix this problem. --Ixfd64 03:18, 1 October 2005 (UTC)

I think it's going to take a developer to fix this one; deleting the target {{disambig}} seems to time out, probably because it has to update so many links table entries. I have at least separated out the prior history, which I left at Template talk:Disambig/History. Noel (talk) 23:25, 3 October 2005 (UTC)
PS: I just happened to see this here by accident. Requests for history merges go at Wikipedia:Cut and paste move repair holding pen. I'll make the pointer to that more prominent. 23:25, 3 October 2005 (UTC)

I merged it. There was no error any more. —Centrx→talk • 17:13, 21 October 2006 (UTC)

Need help with Talk:David Cross and Talk: David Cross (actor)

After making a mistaken move (from the former to the latter) I need an admin to delete Talk:David Cross (currently a redirect) and move Talk:David Cross (actor) into its namespace. Thanks in advance. --TM 05:52, 16 March 2007 (UTC)

History pages messed up.

CV=Christian views about women FS=Frank Stagg (theologian)

Last night, another editor moved article CV into empty article FS, thus moving the CV history page to FS. Then, editor somehow cut and pasted the CV text back into an article with the same CV name. FS has now been added to and is a complete article. But all of CV's history, prior to last night's move, appears on the FS History pages, along with FS History at the top. CV History now looks like CV was created last night, and is a short list.

Now since you are a physicist, maybe you know some kind of magic that will move back to CV those entries under FS History that belong to CV, leaving at the top of each History list the entries that really belong under that article. Clear as mud? I'll appreciate your help very much. Afaprof01 17:29, 29 March 2007 (UTC)

Proposed redesign of Template:Db-histmerge

See Template talk:Db-histmerge#Proposed redesign. —Ilmari Karonen (talk) 01:44, 17 September 2007 (UTC)

Merging histories of duplicate articles

I've just merged the two articles Oaxtepec, Mexico, and Oaxtepec, which were both about the same town. Is it appropriate to request that the history of the one left as a redirect be merged into the history of the other: out of respect for contributors' efforts, GFDL compliance, whatever? The now-redirect -- Oaxtepec, Mexico, the one placed at the wrong location per WP:NC -- actually has a longer history with more contributors. Advice? Aille (talk) 22:59, 20 November 2007 (UTC)

summarizing
Content merge to back to Correct title of contribs (made under that title) reflected in this page's edit history
(In your case, Title with more worthy contributions was a title that should continue as a redirect, even if it had existed so briefly that the likelihood of links having been created on other sites was insignificant.)
The history remains split, between Correct title and Correct title (old contribs), but the set collectively more worthy of recognition are with the article, and the rest are easy for a careful ed-hist reader to locate, thanks to your edit summaries.
--Jerzy•t 05:50, 29 August 2009 (UTC)

Illustration for 'more complex case'

I did my first resolution of a complex cut-and-paste move and found that I really needed to illustrate the process for myself. I mapped it out with the two articles that were involved, then cleaned up the diagram and re-labeled it according to the articles cited in the section Wikipedia talk:How to fix cut-and-paste moves#A more complex case. I have included the image here as a thumbnail and would be interested in knowing whether you agree it would be useful to include in the text itself (as a thumbnail, of course). This was composed in PowerPoint 2003; I could upload the original file if anyone would like to make revisions or recompose from this starting point. (P.S. my own specific case was Boucher and Boucher Manufacturing Company) --User:Ceyockey (talk to me) 02:14, 24 January 2008 (UTC)

Well, it's been more than an year, and no illustrations. I've added a different kind of representation in the page. Jay (talk) 21:24, 3 February 2009 (UTC)
Late comment, and maybe I'm not the right person to comment on this, since I know how the process works, but I have to say the picture doesn't do much for me. Maybe it's because you'd have to keep at least three windows open to look at the instructions, look at the picture (since it doesn't do much at thumbnail size), and do stuff to articles at the same time. In my opinion the simplest thing to do would be to just say "deleted revisions in history won't get moved" since most of the the rest of the steps follow from that, but I'm not sure if everyone else sees it the same way. - Bobet 22:22, 21 May 2008 (UTC)

Question about the 'warning' that was on the page

I removed a warning about having to click on every revision to undelete them (in this edit), since it's not actually true (just click on the first revision, then shift-click the last). However, since it seems like such an obvious thing that has stuck around for so long, is there some issue I'm not aware of? Does that not work with other browsers besides Firefox? - Bobet 22:10, 21 May 2008 (UTC)

question

Would I be accurate in saying that this is project that is best suited to admins? I'd be interested in helping out here a bit from time to time, but as I understand the project page, it appears that most of the abilities that are required would only be available to administrators. How accurate am I in that assumption? — Ched :  ?  16:46, 28 May 2009 (UTC)

David Campbell (British Army officer)

Some time ago I created User:David Underdown/David Campbell (British Army officer), intending ultimately to move it into mainspace. As there was one key source I couldn't get hold of, my work stalled. In the meantime, User:Dormskirk independently created David Campbell (British Army officer), and as I'd forgotten to watch the redlink, I didn't notice for some time. We're now considering the best way to merge the pages while preserving as much history as possible, and wondered if anyone watching this page could give some advice on the best way forward? David Underdown (talk) 14:15, 13 May 2010 (UTC)

Graham87 (talk · contribs) is very experienced doing histmerges. I'd try asking at his talk page. -- œ™ 09:23, 20 May 2010 (UTC)
I am happy with the way things are at that page, with the merge tag on the talk page. Graham87 11:26, 7 August 2010 (UTC)

Which history merge method should be used?

I have been using this history merge method for over two and a half years. The main advantages of that method over the original method are that it doesn't introduce junk redirect edits, it doesn't require the histmerging admin to revert any old edits, it improves transparency, since the history merge tart is in the move log, and the changes in the history take effect immediately. The main disadvantage is that it clutters the watchlist with extra page move entries. I originally mentioned that method on this page in August 2008, but I didn't want to be too bold at the time and re-shape the page. However I think the method that I use is superior to the original method, which was designed before the advent of selective deletion. Graham87 08:02, 7 August 2010 (UTC)

Duplicate talk page

I'd like to have the history of Talk:Automotive Products Trade Agreement merged into Talk:Auto Pact. (The page was moved but the talk page wasn't.) The former is from Feb. 2008 to May 2009. The latter is all before that, save for someone having moved it to an archive and then moved it back. I'm not sure how best to deal with this. Is there a way to request a histmerge or is it better to just move the older one to an archive and have the newer one moved to the main talk page? --Sable232 (talk) 21:07, 31 October 2010 (UTC)

The two pages shouldn't be history merged in this case because they both have different content. Your second proposal is the only sensible option in this case, and I've just done the necessary page moves for it. Graham87 01:27, 1 November 2010 (UTC)
Thanks. --Sable232 (talk) 03:48, 1 November 2010 (UTC)

User to article namespace

If I create a page in user name space before taking it to article namespace, should I move the user namespace page or copy and paste it. I couldn't find anything here elaborating on this, so I wanted to ask first. –Dream out loud (talk) 03:09, 27 December 2010 (UTC)

You should move it. Only copy and paste it if the main namespace page already exists. Graham87 14:13, 27 December 2010 (UTC)

A "troublesome" case

An article was created and edited for awhile at one name - say "A", then an author did a c&p move - to "B" - but did not make the old article redirect to the new one. A few edits were subsequently and independently made to "A" and "B" before someone realized there were two copies of the same article and made A redirect to B. So this is a "troublesome case" and I just moved A to "talk:foo/OldVersion" and B to "foo". see Talk:Teteh_Bangura/OldVersion. But, it seems like it would be ideal if I selectively merged the pre-B edits of A to B? then left the rest of A's edits, deleted, at Talk:Teteh_Bangura/OldVersion? thanks, ErikHaugen (talk | contribs) 07:55, 14 February 2011 (UTC)

Yes, that would be the best course of action. But leave A's edits undeleted, and put an explanation on the talk page of "A" explaining that it contains old edits relating to Teteh Bangura - that page seems to contain significant edits. And write a short note on Talk:Teteh Bangura with a link to Talk:Teteh Bangura/OldVersion. Graham87 14:00, 14 February 2011 (UTC)
So leave just the edits of A that took place after the c&p move at A undeleted there and merge the rest to B? Sounds good. ErikHaugen (talk | contribs) 14:20, 14 February 2011 (UTC)
Yep, exactly. Graham87 15:24, 14 February 2011 (UTC)

Alternative strategy

I've seen this done, I'd like to get people's thoughts:

Say we're merging history from A to B:

  1. Delete B
  2. move A to B, leaving redirect
  3. Delete B again
  4. Restore everything from B except the move

Now, there is no undone move edit with the redirect, ie the droppings cleaned up by step 3 of "An easy case". The downside is that those droppings serve as a sort of indicator of what happened, if you know what to look for. ErikHaugen (talk | contribs) 14:47, 15 February 2011 (UTC)

  • See #Which history merge method should be used? above. That's basically the history merge method that I've used for the last few years. Graham87 02:28, 16 February 2011 (UTC)
  • I move A to B with the move comment "histmerge", and I leave the move edit showing in the end result as a clue that a histmerge has been done. Anthony Appleyard (talk) 13:30, 20 February 2011 (UTC)

My last year edits

Last year I worked on some web browser articles and I made a mistake on two: Agora (web browser) and Argo (web browser). I thought that Argo war later renamed to Agora and so I cut 'n past the content/moved the pages. The revisions before 369200884 (the move) at Agora should be at Argo. Can somebody correct that? I will give help for more understanding if needed. mabdul 18:34, 19 February 2011 (UTC)

Fixed, but I've made this edit the first one at the "Agora (browser)" article, so all revisions where the title is "Argo" are in the Argo revision history, and all revisions where the title is "Agora" are in the "Agora" revision history. Thanks for letting us know. Graham87 04:49, 20 February 2011 (UTC)

Alteration to section "Parallel versions"?

  • Add this text?:
    Also, if page A is to be history-merged into page B, before the process, make sure that page B is not sitting over a deleted parallel history, as then, deleting B will shuffle the history of B and that deleted history together. The deleted history should be first be got out from under B by some process such as this: Move B to some other name, say B_zxcvbnm (not 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 (not making a redirect).
    Similar applies to a page which must be deleted and then partly undeleted for a history-split.

History-merging from a sandbox

I was thinking of inserting this in Wikipedia:Cut and paste move repair holding pen next after section '====Parallel versions====':-

====History-merging from a sandbox====

Sometimes a user uses a sandbox page (say User1/Sandbox1), to create the text of a new article, and when complete, he cut-and-pastes it to page (say) Topic1). After that, he blanks that sandbox and uses that sandbox in the same way to set up a new page Topic2, and then Topic3, and so on up to TopicN. That results in User1/Sandbox1's history containing the early histories of all these topics chained up. If an admin is then asked to history-merge User1/Sandbox1 to TopicN, he should take care that the early histories of the other topics are not dragged across with it into the edit history of page TopicN. Anthony Appleyard (talk) 15:40, 16 July 2012 (UTC)

Anthony Appleyard (talk) 15:40, 16 July 2012 (UTC)

  • Sounds fine to me, for what it's worth. Graham87 20:48, 16 July 2012 (UTC)

Weerawila International Airport → Mattala Rajapaksa International Airport

This airport was planned at least as early as 2006, under the "Weerawila" name. The name changed to "Mattala" between then and now, and was officially opened under the latter name today.

The issue: Both these articles refer to the exact same airport. And considering the significant amount of revisions in the older article (dating back to 2006), I strongly believe a history merge should be done here to preserve history.

  • WIA article created: 04NOV2006
  • MRIA article created: 27NOV2009

Revisions on the WIA article between 27NOV2009 and Today doesn't seem significant, and in my opinion can be deleted to avoid revision conflicts.

Could someone merge these histories please? I could then add info about the old "Weerawila" name in the new article. Rehman 14:02, 18 March 2013 (UTC)

There's no need for that in this case, as far as I can determine. Except for some very rare circumstances, page histories should only be merged when text has been copied word-for-word (or very nearly so) from one article to another; anything else leads to madness. Just merge the articles by hand, noting what you're doing in the edit summaries, and use the {{Copied}} template on the talk page for attribution. The history under the old name is under no danger of being deleted, unless the airport is renamed back to the "Weerawila" name. Graham87 06:18, 19 March 2013 (UTC)
I do agree with you, that we could use the "Copied" templates, and so on. But is there anything against doing this merge? One could consider this a somewhat word-by-word copy, I think. The WIA article will be dead forever, as there is nothing else possible one could put in there, nor will the airport be renamed again (from what we can see now). Just for 'preservation reasons', can we proceed with the merge since it is clearly uncontroversial? The WIA edits dates back too far back to let rot in limbo, IMO. Rehman 13:58, 19 March 2013 (UTC)
In your diff, an awful lot of text was removed. This diff completely rules out a history merge in my mind, because the two texts have almost nothing in common. The only thing that's worth doing is to redirect the Weerawila article to the Mattala page and merge anything that's salvageable, using the "copied" template as I mentioned above. There is absolutely no danger of the Weerawila history being deleted, ever (unless the airport is renamed back or something equally bizarre happens, as I've already said). Graham87 13:11, 20 March 2013 (UTC)

After some research, I've noticed that both these airports were in fact two entirely separate airports; both currently existing and functioning. It was just that during MRIA's early planning, an expansion over Weerawila Airport was also considered (and was to be renamed to WIA). Sorry for any confusion, and thanks for your time, Graham. No merger or splits of any sort is needed here. :) Rehman 03:20, 21 April 2013 (UTC)

Category:Possible AfC copy-and-paste moves

Category:Possible AfC copy-and-paste moves is now a sub-category of Category:Candidates for history merging. Note the word "Possible" in the title. davidwr/(talk)/(contribs)/(e-mail) 19:44, 6 April 2013 (UTC)

New section: How to handle the left-over redirect

I added a new section then reverted the change pending discussion. This change is needed particularly for cases where users use their main User: page to draft articles, then COPY their draft articles into the main encyclopedia or into WP:WPAFC submission space ([[Wikipedia talk:Articles for creation/Article name goes here]]). If the version in their User: space has more than one editor, a history merge is required for copyright reasons (it is desirable even if there is only 1 editor). More than once I've seen a leftover redirect into either WP:WPAFC submission space or into article space, neither of which is desirable. davidwr/(talk)/(contribs)/(e-mail) 16:29, 20 April 2013 (UTC)

In general I don't think a redirect from a user subpage to an article or a Wikipedia talk page is that big a deal; it's very hard to get to the user subpage by accident. However general advice like that is a good idea, and I'd be happy with the proposed new section with a couple of minor changes (for instance, IMO a history merge shouldn't always capture *all* revisions from one page – it should leave redirect revisions and other junk behind). If there are no objections in the next week, it'd probably be a good idea to add your new section wholesale. Graham87 04:55, 21 April 2013 (UTC)
checkYDone, wholesale, without the modifications you suggested for the sake of making a "clean" update (i.e. I'm not "rejecting" your idea at all). Please make your proposed changes or suggest the new exact wording here. davidwr/(talk)/(contribs)/(e-mail) 16:19, 27 April 2013 (UTC)
Done; apart from the change I discussed above, I did some minor copyediting and re-formatting of the text. Graham87 03:39, 28 April 2013 (UTC)

Talk pages

  • A section should be added saying, if history-merging A into B, what to do with pages Talk:A and Talk:B, including if either or both have archives or other subpages. Anthony Appleyard (talk) 07:19, 10 October 2013 (UTC)
    • Would you (or anybody else reading this) agree that it's best to keep an article's corresponding talk page history aligned to the article's edits? That is my guiding principle in this case, and is why I often history merge talk pages that do not have any content in common. For example, if A was moved by cut-and-paste to B, I would history merge Talk:B and Talk:A together (and then do a text merge of the two talk pages), assuming there were few overlapping edits. Graham87 14:43, 10 October 2013 (UTC)
  • This is frequently tricky. Fortunately, an article can have multiple talk pages, so simply moving the less-useful or less-current talk page to Talk:''pagename''/''date-range-here'' or Talk:''pagename''/''History merge from date-range-here'' and putting a link to it at the top of the existing talk page is always an option. If you do a histmerge though, please include a link to entries in the page history where "from-page" changed. davidwr/(talk)/(contribs) 20:10, 10 October 2013 (UTC)
    • Occasionally I'll just move the old talk page to an archive where this is warranted. My main objection to moving it anywhere other than an archive (which admittedly makes far more sense for high-traffic pages) is that links on the top of pages can easily be lost – new users may remove them, whether out of ignorance or malice and if the page is not well-watched, they'd probably never be put back. Creating a new section to note the new link is one solution to this problem. Graham87 04:24, 11 October 2013 (UTC)
  • If I history-merge page A into page B, and both have talk pages, and neither talk page has archives, sometimes I move Talk:A to Talk:B/Archive 1, and insert {{archive}} and {{archives}} tags as needed. Sometimes I find that the talk page was cut-and-pasted at the same time as the article and can be history-merged. Sometimes there are corresponding subpages e.g. A/zxcvbnm and B/zxcvbnm, or Talk:A/zxcvbnm and Talk:B/zxcvbnmn, and sometimes one (which one?) is a redirect to the other, and sometimes the two are independent. Both talk pages may have archives if the cut-and-paste was a long time ago; or one talk page's archives may be redirects to the other talk page's archives. Etc etc complications. Anthony Appleyard (talk) 04:54, 11 October 2013 (UTC)
  • Also watch out if A or B or Talk:A or Talk:B has subpages of other sorts (sandboxes etc). Anthony Appleyard (talk) 12:50, 16 October 2013 (UTC)

Proposed details= parameter for Template:Histmerge

I have updated the documentation for Template:Histmerge and proposed adding a details= parameter.

The intent is to cut down on the need to manually list items at Wikipedia:Cut-and-paste-move repair holding pen if only 2 pages are involved and the details of what needs to be merged in and what needs to be discarded or left behind can be explained without discussion.

See Template:Histmerge/sandbox, Template:Histmerge/testcases, and the proposed documentation for the sandbox version.

If there are no objections I will make this go live in a few days, then if I have time I plan to create a second SUBST-only wrapper of this that includes a section for administrators to make it easy for them to identify the requester and leave a note on his talk page that the request was completed or was declined and why.

Is there any reason not to make the details= parameter go live? Is there any reason not to continue with a SUBST-only wrapper? davidwr/(talk)/(contribs) 19:02, 21 October 2013 (UTC)

This change is now live. davidwr/(talk)/(contribs) 17:17, 31 October 2013 (UTC)

Help please

Lower history size/article size limit?

  • I just requested histmerge at The People's Voice (internet TV station). But it suddenly struck me that somebody might yell "that's silly". So, what are the lower limits, below which we don't bother with history merging? Stubs? --Lexein (talk) 19:08, 8 December 2013 (UTC)
  • As far as I'm concerned, there aren't any. Graham87 02:31, 9 December 2013 (UTC)
  • Histmerge  Done. Anthony Appleyard (talk) 08:42, 9 December 2013 (UTC)
Good to know, all. Thanks. --Lexein (talk) 18:38, 10 December 2013 (UTC)

UEFA Nations League

Hi, would this be elgible for a history merge? I created a page at Nations League, which was rapidly redirected. Should the histories be merged? Thanks, Matty.007 21:01, 26 March 2014 (UTC)

Eligible for? Perhaps, but there is a simpler solution: Since you, Matty.007, are the only author of Nations Leauge, you can just update UEFA Nations League with any content from the last pre-redirect version of Nations League then put a {{db-author}} tag on "Nations League" in place of the redirect and put a link to this discussion in an HTML comment or in the edit summary. Once the page has been deleted, you can re-create the redirect if you think it's worth having one. Had other editors made significant changes then this would not be an option. davidwr/(talk)/(contribs) 22:10, 26 March 2014 (UTC)
Nope, it's not eligible for a history merge, because no cut-and-paste move was involved. Also, the text from "Nations League" was already merged into UEFA Nations League. The "Nations League" redirect should not be deleted at all; it's a plausible search term ... and there's no reason to delete its history, either. Graham87 03:09, 27 March 2014 (UTC)
History mergers are sometimes used to consolidate things when two articles about the same topic have non-overlapping histories and there is a text-merge from the older article into the newer one. Alternatives include turning the older one into a redirect, as is the case here, moving the older one into a talk-sub-page and making it a redirect for the purposes of preserve the history, or moving the older one into a page called pagename (2) or pagename (old) or some such and turning it into a redirect. None of these 3 alternatives are ideal, but I've seen each used at least once in my time on Wikipedia. davidwr/(talk)/(contribs) 03:26, 27 March 2014 (UTC)
Is there any need to have the copy paste of info here mentioned on the talk, or is it fine un-attributed? Thanks, Matty.007 17:21, 27 March 2014 (UTC)
Oops, I missed that. The presence of someone else copying your contribution from one page to another invalidates my "simple solution" above. There needs to be something on the newer article's talk page for attribution purposes. This can be a copy-and-paste of the edit history or a back-link to the old article. There should also be a note added to the redlink page Talk:Nations League saying that the corresponding article should not be deleted as long as UEFA Nations League exists, due to attribution requirements. davidwr/(talk)/(contribs) 17:43, 27 March 2014 (UTC)
Is Talk:Nations League and Talk:UEFA Nations League OK? Thanks, Matty.007 17:48, 27 March 2014 (UTC)
It is now. I added {{copied}} and used your information to fill in the parameters. I removed your "top of the talk page" text from the newer article as it is now redundant with the standardized template. davidwr/(talk)/(contribs) 18:02, 27 March 2014 (UTC)

Thank you for all the help. Matty.007 18:29, 27 March 2014 (UTC)

Backwards?

Aren't the directions backwards? The {{histmerge}} tag text makes it seem as if it belongs at the site of the cut, not at the new page paste czar ♔ 03:30, 30 April 2014 (UTC)

No, it looks correct to me:
It is requested that the page history of some other page be merged into the history of this page. This action must be performed by an administrator. (emphasis added)
"This page" is the newer, copied-to page, "some other page" is the older, copied-from page. More often than not, people copy from "draft" pages into the main encyclopedia, so you want the new page name to be the "final" page name. If the desired page name is the "original" page, then you can use the "reason" or "details" parameter to request that the content be placed in the location of the original page. davidwr/(talk)/(contribs) 21:29, 30 April 2014 (UTC)

New barnstar - Template:The History Merger's Barnstar

This isn't on the "official" barnstar list yet, but I've opened a discussion at Wikipedia talk:WikiProject Wikipedia Awards#The History Merger's Barnstar - new award about it.

It should be a shock to nobody that I gave the first one of these to Anthony Appleyard, "For [his] tireless efforts splicing and dicing pages after copy-and-paste moves" (diff). davidwr/(talk)/(contribs) 18:31, 6 May 2014 (UTC)

Idea for an edit to "An easy case"

Make a hard reload (Shift+Control+R in Mozilla or Opera and Ctrl + F5 in Internet Explorer) to see an up-to-date history reflecting the undeletion.1

by

Make a hard reload (Shift+Control+R in Mozilla or Opera, and Ctrl+F5 in Internet Explorer, and Ctrl+R in Firefox) to see an up-to-date history reflecting the undeletion.1

?? Anthony Appleyard (talk) 05:39, 27 May 2014 (UTC)

Thanks, done, with some minor tweaks. However you could have made the edit yourself. Graham87 02:15, 28 May 2014 (UTC)

Newly enabled special page to automate history merges

Special:MergeHistory, a special page that can automate history merges, has recently been enabled on the English Wikipedia. It's currently being discussed on the admin's noticeboard. Graham87 02:45, 23 July 2014 (UTC)

A suggestion for an insertion in page Wikipedia:How to fix cut-and-paste moves

  • Before the line "==How to undo a history merge==", insert this section:- (Anthony Appleyard (talk) 08:56, 15 October 2014 (UTC))
`````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````````

===History-merging a transcluded page===
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. The admin performing the history-merge should not try to perform a history-merge on page Y, but only on page X. This is likeliest to happen if page X is a template, but it may happen to any page which is transcluded.

Thanks; added, with a few tweaks. Graham87 15:00, 15 October 2014 (UTC)

Resident Evil Survivor 2 Code: Veronica

An article for Resident Evil Survivor 2 Code: Veronica was recreated recently. It previously existed in 2009 under a different title before it was redirected (notice the colon after "Resident Evil"): https://en.wikipedia.org/w/index.php?title=Resident_Evil:_Survivor_2_Code:_Veronica&oldid=330064630

I added a history merge tag to the article but was reverted: User_talk:Mika1h#RE Survivor 2. Should the histories of the articles merged or not? The current article doesn't continue the work of the previous article. The article is moved but it's not a cut-and-paste move. --Mika1h (talk) 13:56, 31 October 2014 (UTC)

History merges should only be performed to fix cut and paste moves. As you know, that's not what happened in this case. Graham87 07:26, 1 November 2014 (UTC)

Discussion regarding titling standards for moving parallel histories

The ten cases referred to below were technical move requests (permalink)
  • All 10 of these were cases where I had to move page X (usually largely composed of old redirects) to somewhere else to allow requested move X (disambiguation) to X and history-merge was not suitable, or not possible because of WP:Parallel histories. Anthony Appleyard (talk) 05:38, 3 September 2015 (UTC)
  • @Anthony Appleyard: Before I go into this too much, I want to say thank you so much for all of the work you do on the English Wikipedia to fix edit histories by merging pages together; you do more merges, and accurate merges nonetheless, than any other administrator on here, and for that, you really do deserve all the credit and barnstars that anyone can ever receive. I really am glad that there is an individual who is able to skim through those day by day, fulfilling the edit history merge requests and not get burnt out on it, seriously. Anyways, yes, I'm quite aware that you are the one that creates those titles. The issue with those titles being functional redirects, in my opinion, is that they create very odd, very unlikely titles for redirects that really shouldn't exist. I don't know if there is an acceptable alternative location to move these histories, but what I have been doing in one way or another has been trying to move the alternate version to a plausible search term (such as moving a parallel version of Foo (film) to Foo (1987 film)). That way, the edit history is still somewhere, but it's not hiding in a redirect that isn't helpful as a search term. Occasionally during the past few years, I've trying to brainstorm for other ways to resolve this issue I've seen, and this was the best resolution that I came up with. As you saw on my requests at WP:RMTR that you removed, it becomes a bit more complicated to move any parallel versions of a disambiguation page anywhere since the only two community-acceptable titles for a disambiguation page per WP:DABNAME are the ambiguous title and the title with "(disambiguation)" at the end. I'd really like to look for and discuss possible solutions to this, especially since there seems to be a constant consensus to delete these redirects as unhelpful on WP:RFD. Also, another item to consider is that anyone looking for actual titles of articles or redirects named "version X" get blogged down having to skim through all of these parallel history redirects prior to finding an actual article with "version X" in its subject's title. Steel1943 (talk) 06:15, 3 September 2015 (UTC)
    • (edit conflict) (Butting in...) I think Steel gets why they were moved out of the way, s/he are just requesting that the old history be put at a location that is (a) more likely to be found if anyone is looking for it, and (b) less likely to be deleted by a passing admin who doesn't understand what's happened, e.g. what happened to Trey Smith (version 2). Generally I think that, if there is an obviously suitable place for the histories like with these dab pages, it would be preferable to have them there rather that at a version 2 type place. This actually reminds me a bit of Talk:Node of Ranvier#Page history of merged article, which we never got a great resolution on. Pinging the users who commented there in case they're interested: Andrewa, Graham87, Wbm1058, Fuhghettaboutit. For clarity, these are the requests Steel made. Jenks24 (talk) 06:16, 3 September 2015 (UTC)
  • @Andrewa, Graham87, and Jenks24: I am unwilling to merely let the old edits of page X sit deleted under the edits moved from X (disambiguation) to X, as that is liable to accidents (see WP:Parallel histories) if, some time after that, page X must be temporarily deleted and then undeleted (e.g. for history-merge or history-split). Anthony Appleyard (talk) 09:11, 3 September 2015 (UTC)
  • @Anthony Appleyard: I don't disagree with your logic: I disagree with the titles of the pages which the parallel histories are being moved. There has to be a different way to name these parallel pages... Steel1943 (talk) 09:18, 3 September 2015 (UTC)
I agree a best solution for complex cases like these should be agreed upon and documented, and having just successfully run for admin on a platform of working the hist-merge beat, I hope to help with that. But for now, I first intend to start by working on the easy ones to get my feet wet. After I have some experience with that, I may have a better idea about the best approach for the complex cases. – Wbm1058 (talk) 11:01, 3 September 2015 (UTC)
As I said at the discussion Jenks24 linked, I think a history swap in such cases – especially with an explicit edit summary flagging the reason for the swap and therefore that it should not be deleted – is the best method. It avoids the issue that prompted this entirely and requires no extra page like "version 2" to be created under any title; you start with two pages and end with two pages. Take for example the first request, which was a fulfilled technical request to move Pashtun (disambiguation) → Pashtun as unnecessary disambiguation. The history swap method would be:
  1. Move Pashtun to Pashtun/temp, with an edit summary like "History swap; preserving redirect with non-trivial page history", or if there's a merge in the history, something like this (suppress creating a redirect)
  2. Move Pashtun (disambiguation) to Pashtun, with the normal edit summary (suppress creating a redirect)
  3. Move Pashtun/temp to Pashtun (disambiguation), with an edit summary like "completing history swap" (suppress creating a redirect).
  4. Retarget the redirect at Pashtun (disambiguation), now containing the non-deleted history, to point to Pashtun, as at that point it will be pointing at itself.
This is captured at Wikipedia:Requested moves/Closing instructions#Edit history of destination page (though I did not provide any suggestions there about the edit summaries).--Fuhghettaboutit (talk) 01:52, 4 September 2015 (UTC)

Move to new home at WP:NAS

WP:NAS = new admin school, which is soon to be just Wikipedia:Administrators' guide (which redirects to Wikipedia:Administrators' how-to guide, which we're also doing away with).

OK, so basically WP:NAS is going to be the centralized place where admins can refer to on how to do common tasks. One of those tasks is merging page histories. The page Wikipedia:How to fix cut-and-paste moves is essentially aimed at admins, so I think it should be moved over to this new admin guide in its entirety. This is part of an overall goal to keep admins informed on how to go about their duties from day one, as "learning on the job" can lead to mistakes.

Thoughts? Discussion is also at WP:BN#Admin how-to guide and new admin school. — MusikAnimal talk 20:42, 8 November 2015 (UTC)

Merging two talk pages when both have been used recently

At the moment we have Talk:DNA history of Ancient Egypt and Talk:DNA history of Egypt. But DNA history of Ancient Egypt is a redirect to DNA history of Egypt. Talk:DNA history of Ancient Egypt is the oldest but somehow a new editor found it and has been using it, and I've replied. I'm not sure what the best way is to merge the two talk pages. Thanks. Doug Weller talk 11:12, 3 January 2016 (UTC)

They can't be histmerged because of the overlapping edits. Just cut-and-paste anything from Talk:DNA history of Ancient Egypt that should be at the new talk page to Talk:DNA history of Egypt (because people's comments have their signatures you don't need to worry about attribution). Then either add a notice at the top of Talk:DNA history of Ancient Egypt instructing any further discussion to go to Talk:DNA history of Egypt or just turn it into a redirect to Talk:DNA history of Egypt. Jenks24 (talk) 11:22, 3 January 2016 (UTC)
Thanks. These pages are a bit of a mess. I've just discovered Talk:DNA history of Egypt/Archive 2 although Talk:DNA history of Egypt doesn't mention archives, and I see no evidence that there's an archive 1 or that Lowercase sigmabot III was set up to do this. Doug Weller talk 11:55, 3 January 2016 (UTC)
I've fixed up the archiving; it was set up incorrectly in this edit. I've seen much worse. Graham87 14:50, 3 January 2016 (UTC)
Thanks, I shall tell him off for not using an edit summary when I reply to him about the 2 talk pages. Doug Weller talk 15:29, 3 January 2016 (UTC)

Auxiliary name in the troublesome case

Section A troublesome case recommends "you can archive the duplicate page to Talk: space (i.e. by moving it to some suitable title, such as Talk:RandomArticle/OldVersion)". I just tried that (for the case discussed at Talk:Finnic peoples#Follow-up on move), but I got a database timeout error, and then I got cold feet since I wasn't sure that that would give me the opportunity to enter a different name, and I didn't want to mess up things more than they already are. Does the undelete dialog offer that opportunity in this case, or does one need to move the target out of the way before? — Sebastian 23:15, 17 February 2018 (UTC)

@SebastianHelm: I've seen these "timeouts" many times. What I've found is that when you try again, they usually succeed on the second attempt. I don't know why that behavior is so typical.
I've sorted out a lot of complex cases like this. I'll dig into this one and hopefully sort it out. I see there are 451 deleted edits hiding underneath Finnic peoples. You don't want to restore those while the article is sitting there. The current article will need to be moved to some temporary location, such as Draft:Finnic peoples, so the deleted history can be restored and moved to its proper home. It can take a lot of time (detective work) to clean up cases like this. wbm1058 (talk) 00:20, 18 February 2018 (UTC)

Page movers and round-robin moves

Thank you, Wbm1058, for your replies in the previoius section and at Talk:Finnic peoples. I agree that this is frustrating, so I wonder how best to learn from it and prevent similar frustrations in the future. In the other talk, you guys mention both the page-movers and "round-robin" moves, neither of which I had known about. I think that should be advertised more; on this page, as well as on Wikipedia:Moving a page. ("Round-robin" appears on the latter, but only under the headline "Swapping two pages", which wasn't what I thought we needed.) "Page movers" does occur on Wikipedia:Moving a page in a way that I read as simply meaning "anyone who has file mover rights", but it you're talking of people who have special experience and use tools other admins are not familiar with. I think it would help if at least these two pages clearly advised to turn to them in cases like Finnic peoples. — Sebastian 01:31, 18 February 2018 (UTC)

See WP:Page mover and particularly WP:Page mover § Round-robin page moves. That's how most moves are done by those who don't have the admin bit. I'm not sure whether there is actually anything to cut-paste repair in this particular case, it's probably just a WP:MERGE that needs to be documented. – wbm1058 (talk) 01:40, 18 February 2018 (UTC)

Request for page history advice

There is an open RfD where the apparent consensus is that the page history should be preserved, but we don't want to keep the redirects, yet histmerge is inappropriate because of parallel page histories. Any advice will be appreciated. Deryck C. 15:26, 23 October 2018 (UTC)

Old bugs

@Graham87: It's been nearly a decade since the "Old bugs" section was changed to the "Bugs" section because "these bugs still occur". These "minor bugs" which have been documented here since September 2005 are by now ancient history in MediaWiki. So, unless these definitely still exist, in which case we should have links to Phabricator bug reports, I'd like to remove Wikipedia:Administrators' guide/Fixing cut-and-paste moves § Lost history bug and Wikipedia:Administrators' guide/Fixing cut-and-paste moves § Former bugs. I fear all these reported problems could be discouraging more admins from even trying to do history merges. These instructions need to be simplified, and should focus on actual known current problems, such as Wikipedia:Administrators' guide/Fixing cut-and-paste moves § Wikidata. I suppose some problems could still exist in the Wikipedia:Administrators' guide/Fixing cut-and-paste moves § Manual process that I haven't seen, because I almost always use the MergeHistory special page. I think the "manual process" should mostly be deprecated in favor of using the special page. Being a relative newcomer to this, I started out by learning how to use Special:MergeHistory and haven't even familiarized myself with all the ins-and-outs of the "manual" process. Of course even using the special page is something of a manual process because of the need to check for old redirects on the target page, and then delete and restore the target page to remove the old redirects if there are any.

Another reason I want to remove the old bugs is that I have a "new" bug to report (actually not that new, just not documented here yet). – wbm1058 (talk) 22:00, 8 February 2019 (UTC)

Perhaps move the old bugs to a subpage? I think they do have some historical value, and they're linked in a footnote.
I have no idea what possessed me to make the edit linked above ... looking at my contribs at the time, it seems that something happened at Armenian education in the Ottoman Empire, but I can't remember what it was. These bugs probably only affect history merges done in the manner described at "An easy case" section. I prefer to do almost all history merges using the method described at "Merging page histories of pages with many revisions", because it makes more sense to me (I added that section to the page). I'm not as big a fan of the merge-history special page (though sometimes it can be indispensable) because it only logs on the source page (the old page name), not the target (the new one), so it can be hard to tell whether a page has had a history-merge. Graham87 06:09, 9 February 2019 (UTC)
OK, I moved the old bugs to Wikipedia:Administrators' guide/Fixing cut-and-paste moves/Old bugs. I hear you about the problem with logging on only one side of the transaction, it would be nice if both sides were logged, but I don't feel it's that big of a deal. It's subtle, but here is how to spot a histmerge boundary (example page history segment below):
  • 03:45, 14 July 2006‎ . . (11,829 bytes) +11,829‎
  • 01:08, 8 July 2006‎ m . . (12,957 bytes) -1‎
You can tell that the edit that added 11,829 bytes is a histmerge-move because the previous version was 12,957 bytes, not 0 bytes. I'm working on adding a new subsection to the Bugs and problems section. wbm1058 (talk) 14:23, 10 February 2019 (UTC)
Sounds good. Re logging: that's nifty! But it requires paying a lot of attention to byte size differences (maybe it's the way I read history pages with my screen reader, but that's not so easy here) ... and it'd be very hard to find history-merges on pages with many revisions. It also probably shouldn't work that way, anyway; the size difference system is completely messed up (e.g. see T193211). I don't feel strongly enough about it to object if you or anybody else uses the special page for some or all of their history-merging; I'm just reluctant to use it myself. Graham87 15:23, 10 February 2019 (UTC)
Right, it's not the most obvious or intuitive way of indicating where the history-merge points are. I just found, and commented on T76557. Also I've added § Co-mingled page-move revisions are inseparable in deleted histories. – wbm1058 (talk) 22:17, 10 February 2019 (UTC)

It is not a copy:

It is not a copy of any content. It is a completely original new article with complete information on a made-in-India app developed by Microsoft for business communication amng groups and individuals. The sources and citations were authentic taken from credible references. Therefore I request you to help me on how to publish this page. Thanking you all. Nagsail (talk) 03:54, 22 July 2019 (UTC)

This editor is referring to their draft article, Draft:Microsoft Kaizala. I see no cut-and-pasting, therefore there is no cut-and-paste move to repair, and thus this section is off-topic for this talk page. – wbm1058 (talk) 13:56, 22 July 2019 (UTC)

Clearing away merge-blocking redirects

In cases where there's no existing redirect, I've made an empty page in draftspace, history-merged the merge-blocking redirects to the draft page, completed the history merge I wanted, and then deleted the draft page under G6. Is this reasonable or should I stop? Wikiacc () 19:04, 6 June 2020 (UTC)

Sounds reasonable to me. I for one move the blocking redirects to a /Temp subpage, but moving them to draftspace works too. Graham87 09:24, 7 June 2020 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:History_merging/Archive_1&oldid=1141735449"