+[[!meta date="2010-03-01 13:14:48 +0000"]]
+
Any wiki with a form of web-editing enabled will have to deal with
spam. (See the [[plugins/blogspam]] plugin for one defensive tool you
can deploy).
Once you are confident it's clean:
- # ensure you are on the doc branch
+ # ensure you are on the master branch
$ git branch
doc
* master
the last merge into master are either spam or spam reverts) then `git rebase`
will abort. Therefore, this approach only works if you have at least one
non-spam commit to the documentation since the last merge into `master`. For
-this reason, it's best wait to tackle spam with reverts until you have at least one
-commit you want merged back into the main history.
+this reason, it's best to wait until you have at least one
+commit you want merged back into the main history before doing a rebase,
+and until then, tackle spam with reverts.