doc/tips/spam_and_softwaresites.mdwn

   1 Any wiki with a form of web-editing enabled will have to deal with
   2 spam. (See the [[plugins/blogspam]] plugin for one defensive tool you
   3 can deploy).
   4
   5 If:
   6
   7  * you are using ikiwiki to manage the website for a [[examples/softwaresite]]
   8  * you allow web-based commits, to let people correct documentation, or report
   9    bugs, etc.
  10  * the documentation is stored in the same revision control repository as your
  11    software
  12
  13 It is undesirable to have your software's VCS history tainted by spam and spam
  14 clean-up commits. Here is one approach you can use to prevent this. This
  15 example is for the [[git]] version control system, but the principles should
  16 apply to others.
  17
  18 ## Isolate web commits to a specific branch
  19
  20 Create a separate branch to contain web-originated edits (named `doc` in this
  21 example):
  22
  23     $ git checkout -b doc
  24
  25 Adjust your setup file accordingly:
  26
  27     gitmaster_branch => 'doc',
  28
  29 ## merging good web commits into the master branch
  30
  31 You will want to periodically merge legitimate web-based commits back into
  32 your master branch. Ensure that there is no spam in the documentation
  33 branch. If there is, see 'erase spam from the commit history', below, first.
  34
  35 Once you are confident it's clean:
  36
  37     # ensure you are on the master branch
  38     $ git branch
  39       doc
  40     * master
  41     $ git merge --ff doc
  42
  43 ## removing spam
  44
  45 ### short term
  46
  47 In the short term, just revert the spammy commit.
  48
  49 If the spammy commit was the top-most:
  50
  51     $ git revert HEAD
  52
  53 This will clean the spam out of the files, but it will leave both the spam
  54 commit and the revert commit in the history.
  55
  56 ### erase spam from the commit history
  57
  58 Git allows you to rewrite your commit history.  We will take advantage of this
  59 to eradicate spam from the history of the doc branch.
  60
  61 This is a useful tool, but it is considered bad practise to rewrite the
  62 history of public repositories. If your software's repository is public, you
  63 should make it clear that the history of the `doc` branch in your repository
  64 is unstable.
  65
  66 Once you have been spammed, use `git rebase` to remove the spam commits from
  67 the history.  Assuming that your `doc` branch was split off from a branch
  68 called `master`:
  69
  70     # ensure you are on the doc branch
  71     $ git branch
  72     * doc
  73       master
  74     $ git rebase --interactive master
  75
  76 In your editor session, you will see a series of lines for each commit made to
  77 the `doc` branch since it was branched from `master` (or since the last merge
  78 back into `master`). Delete the lines corresponding to spammy commits, then
  79 save and exit your editor.
  80
  81 Caveat: if there are no commits you want to keep (i.e. all the commits since
  82 the last merge into master are either spam or spam reverts) then `git rebase`
  83 will abort. Therefore, this approach only works if you have at least one
  84 non-spam commit to the documentation since the last merge into `master`. For
  85 this reason, it's best to wait until you have at least one
  86 commit you want merged back into the main history before doing a rebase,
  87 and until then, tackle spam with reverts.