Wikipedia talk:How to fix cut and paste moves

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

Retrieved from "http://en.wikipedia.org../../../h/o/w/Wikipedia_talk%7EHow_to_fix_cut_and_paste_moves_5cae.html"