X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/3f104d1eb7cc15dec0d3a7a67db85fbe63484281..c2f784d2ad08d1656e5cd7ee2054cf092bb56ce6:/doc/todo/web_reversion.mdwn diff --git a/doc/todo/web_reversion.mdwn b/doc/todo/web_reversion.mdwn index 900d98591..841fc3703 100644 --- a/doc/todo/web_reversion.mdwn +++ b/doc/todo/web_reversion.mdwn @@ -24,16 +24,16 @@ Implementation plan: and refresh site. Peter Gammie has done an initial implementation of the above. -[[!template id=gitbranch branch=peteg/revert author="[[peteg]]"]] +[[!template id=gitbranch branch=peteg/revert author="[[users/peteg]]"]] ->> It is on a separate branch now. --[[peteg]] +>> It is on a separate branch now. --[[users/peteg]] > Review: --[[Joey]] > > 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]] +>> Fixed, I think. --[[users/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 @@ -45,17 +45,16 @@ Peter Gammie has done an initial implementation of the above. > structure that `rcs_recieve` does. This could be done by using `git revert > --no-commit`, and then examining the changes, and then `git reset` to drop > them. ->> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[peteg]] +>> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[users/peteg]] > > Then the code that is currently in IkiWiki/Receive.pm, that calls > `check_canedit` and `check_canremove` to test the change, can be > straightforwardly refactored out, and used for checking reverts too. ->> Wow, that was easy. :-) -- [[peteg]] +>> Wow, that was easy. :-) -- [[users/peteg]] > > (The data from `rcs_preprevert` could 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.) ->> I added `rcs_showpatch` which simply yields the output of `git show `. -- [[peteg]] > > Note that it's possible for a git repo to have commits that modify wiki > files in a subdir, and code files elsewhere. `rcs_preprevert` should @@ -63,28 +62,12 @@ Peter Gammie has done an initial implementation of the above. >> Taken care of by refactoring `rcs_receive` in `git.pm` >> I've tested it lightly in my single-user setup. It's a little nasty that the `attachment` plugin >> 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]] +>> Please look it over and tell me what else needs fixing... -- [[users/peteg]] ->>> I have made my own revert branch and put a few fixes in there ->>> (and fixed all the indention..). Issues I noticed but have not gotten ->>> to: --[[Joey]] ->>>> Please change the git pointer above, then. I will work on your branch. -- [[peteg]] ->>> ->>> * `rcs_diff` already exists; why add `rcs_showpatch`? ->>>> If `rcs_diff` is intended for human consumption, by all means we can use that. -- [[peteg]] +>>> I have made my own revert branch and put a few^Wseveral fixes in there. +>>> All merged to master now! --[[Joey]] ->>> * Would it be better for `rcs_revert` to not commit, and ->>> `rcs_commit_staged` to then be used? This would work for git, but ->>> maybe other RCSs would be problimatic. It would simplifiy the ->>> interface and allow for future mulitple-revert interfaces. ->>> * I quite don't understand why one caller of `git_parse_changes` ->>> needs it to chdir, and not the other one. It's running ->>> in the same git repo either way, and git doesn't need ->>> `git show` to run in a subdir at all.. ->>>> I was aping (preserving) what was already there. I don't understand what you say about `git show` - it must run under $srcdir, surely? And empirically the CGI process wasn't in the right place. By all means simplify that. -- [[peteg]] - ->>> * Probably needs to untaint the revs passed in. ->>> * Seems backwards for `rcs_preprevert` to import and ->>> use `IkiWiki::Receive`. ->>>> Indeed. This is saying that the checking code in IkiWiki::Receive is in the wrong place. I think it would be better to set up some general hooks and shuffle it into a plugin, for then other plugins that maintain special files in the repo can have a say about validity. -- [[peteg]] +[[done]]