Last modified: 2006-12-05 14:47:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6925 - History patching: allow old edits to be reversed
History patching: allow old edits to be reversed
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
History/Diffs (Other open bugs)
1.8.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 4730 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-04 20:52 UTC by Lupin
Modified: 2006-12-05 14:47 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Lupin 2006-08-04 20:52:24 UTC
I can currently rollback the final n edits to an article easily. What I can't do
is reverse the effect of non-final edits without merging by hand. What I'd like
is to be able to get mediawiki to do the equivalent of 

diff -u old_bad_rev old_good_rev | patch current_rev

in the cases that such a patch applied cleanly. The situation I've encountered
where this would be handy is where vandalism has been missed, and subsequent
good edits made.

UIwise, such a feature would sit nicely on a diff page, I feel.
Comment 1 Andrew Garrett 2006-11-07 21:54:31 UTC
I would really like to see this feature. I don't have the diff expertise to know
how to do it, though. I would strongly support any fix for this bug (and I'll
tes any patch that is submitted, and commit it if it works)
Comment 2 Rotem Liss 2006-11-08 13:32:21 UTC
It should use diff3, I think, and should be disabled if diff3 is not exist.
Comment 3 Rob Church 2006-11-08 15:01:44 UTC
Good lord, that's revolutionary. It should use diff3. Stop the presses, we've
solved world hunger, lads. Use diff3!

*No shit*. What we *want* is a thorough idea of how to go about implementing it,
not just the underlying code, but also how we'll present it to the user.
Comment 4 Lupin 2006-11-26 01:46:39 UTC
For the user interface, I had something like the following in mind. On a diff
page, include a link labelled "undo this edit". If the operation fails, then go
back to the diff page with a "sorry, couldn't do it" message at the top.
Comment 5 Andrew Garrett 2006-11-26 10:54:13 UTC
Fixed in r17935.
Comment 6 Lupin 2006-11-30 01:39:24 UTC
The current undo functionality, while nice, can only undo a single edit. Could
it be enhanced to undo an arbitrary number of edits? When I click undo on a diff
between oldrev and newrev, I expect to undo all the intermediate edits, not
merely the final edit.
Comment 7 Rob Church 2006-11-30 08:16:32 UTC
I thought the whole *point* was to be able to undo an edit which wasn't in
sequential order?
Comment 8 Lupin 2006-11-30 10:11:46 UTC
No, the point was to be able to undo one *or more* edits that are not the final
edit. I'll try to clarify. Consider an article with four consecutive revisions,
r1,r2,r3,r4.

If I view the diff page for diff(r2,r3) I can currently hit undo to try to patch
r4 with diff(r3,r2). This is good.

However, if I view diff(r1,r3) and hit undo, r4 is still just patched with
diff(r3,r2); that is, only one edit is undone. I think that r4 should be patched
with diff(r3,r1) to undo the cumulative effect of both edits between r1 and r3.
This would be useful if, for example, both of these edits are vandalism.

The current behaviour is also confusing, as the effect of hitting undo does not
correspond with what is displayed on the diff page diff(r1,r3).
Comment 9 Andrew Garrett 2006-11-30 10:14:43 UTC
Make a new bug report for this additional functionality. This bug, as described,
has been fixed.
Comment 10 Rotem Liss 2006-12-05 14:47:24 UTC
*** Bug 4730 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links