Mar 2 2019
Many of the history-merge requests that I get are not suitable for Special:MergeHistory , but are done quicker (or only) by the old method. Please keep selective undelete of edits, and please add selective delete of edits. Removing the ability to selectively delete a page's non-deleted edits and also the ability to selectively undelete a page's deleted edits, would handcuff me badly. As well as requests for clean classical history-merges, I also get requests for various sorts of tidying-up after many sorts of unwise actions by users.
Mar 1 2019
See https://en.wikipedia.org/wiki/Talk:Black_sheep/Archive_1#Moves,_merges,_history for a complicated job that I had on 11 October 2007 tidying up pages about "Black Sheep".
Feb 28 2019
... and "deleted revision" could refer to either a revision that's in the archive table because ...
In my experience, if I do not have selective delete of edits, I would certainly need selective undelete of edits like we have now.
If there was a "selective revision move" feature ...
Feb 27 2019
Feb 26 2019
In an edit history of non-deleted edits (e.g. https://en.wikipedia.org/w/index.php?title=Scuba&action=history ), the details of each edit include a small square check. That is to select edits to be hidden. But with some reprogramming it could also be used to select edits for other purposes.
Feb 25 2019
More simply :: sometimes in my work, I need to delete some edits of a page's edit history. But I cannot :: I must delete all of that page's edits, then undelete some of them. That wastes internet link time and Wikipedia server time. That is why selective delete is needed.
Jan 30 2019
I have written Proposal 1 at the Community Wishlist Survey 2019, ...
One administrator on Wikipedia who frequently does history merges is Anthony Appleyard. If either proposal passes, then that user would have to start using "Special:MergeAndMove" to do history merges, and would no longer need to "revert histmerge junk" after doing so.
If I am asked to history-merge page X (source) to page Y (destination), problems that arise are:-
- Edits made to X after the cut-and-paste event: redirects, BattyBot and other bot edits, edits by someone starting a new article on the subject X or on another subject also describable as X.
- Edits made to Y before the cut-and-paste event, often including redirects.
- Miscellaneous old or new pre-existing deleted edits listed at page name X or Y.
Jan 18 2019
Jan 13 2019
Jan 12 2019
Jul 20 2018
(1) One long-term fault is that an admin can't delete some edits of a page, but he must delete all the edits and then undelete the edits that he wants to stay undeleted. That wastes his time and Wikipedia's system time. This need arises if he is history-merging X (older page) to Y (newer page), and first he must lose from the end of X any stray late edits (e.g. redirects and BattyBot edits) made after the cut-and-paste event. This process is liable to accidents if the page already has deleted edits at the start of this process.
(2) Currently, moving a page only moves the undeleted (visible) edits. It would be useful if it was also possible to move only the deleted edits, when fishing deleted edits out from under visible edits , to prevent the sort of accident described at the end of (1).