Goal: Web interface to allow reverting of changes.
At least at first, it will be exposed via the recentchanges page, with revert icons next to each change. We may want a dynamic per-page interface that goes back more than 100 changes later.
- No support for resolving conflicts in reverts; such a revert would just fail and not happen.
- No support for reset-to-this-point; initially the interface would only revert a single commit, and if a bunch needed to go, the user would have to drive that one at a time.
rcs_reverthook that takes a revision to revert.
- recentchanges plugin adds above to recentchanges page
- prompt user to confirm (to avoid spiders doing reverts), check that user is allowed to make the change, commit reversion, and refresh site.
Peter Gammie has done an initial implementation of the above.
It is on a separate branch now. --peteg
The revert commit will not currently say what web user did the revert. This could be fixed by doing a --no-commit revert first and then using rcs_commit_staged.
Fixed, I think. --peteg
So I see one thing I completly forgot about is
check_canedit. Avoiding users using reverting to make changes they would normally not be allowed to do is tricky. I guess that a easy first pass would be to only let admins do it. That would be enough to get the feature out there..
I'm thinking about having a
rcs_preprevert. It would take a rev and look at what changes reverting it would entail, and return the same data structure that
rcs_recievedoes. This could be done by using
git revert --no-commit, and then examining the changes, and then
git resetto drop them.
We can use the existing
git_commit_infowith the patch ID - no need to touch the working directory. -- peteg
Then the code that is currently in IkiWiki/Receive.pm, that calls
check_canremoveto test the change, can be straightforwardly refactored out, and used for checking reverts too.
Wow, that was easy. -- peteg
(The data from
rcs_preprevertcould also be used for a confirmation prompt -- it doesn't currently include enough info for diffs, but at least could have a list of changed files.)
Note that it's possible for a git repo to have commits that modify wiki files in a subdir, and code files elsewhere.
rcs_preprevertshould detect changes outside the wiki dir, and fail, like
Taken care of by refactoring
git.pmI've tested it lightly in my single-user setup. It's a little nasty that the
attachmentplugin gets used to check whether attachments are allowed -- there really should be a hook for that.
I agree, but have not figured out a way to make a hook work yet. --Joey
Please look it over and tell me what else needs fixing... -- peteg
I have made my own revert branch and put a fewWseveral fixes in there. All merged to master now! --Joey