*  A file that contains trade secrets or that is under someone else's
     copyright was accidentally committed and needs to be backed out.

  *  A malformed control artifact was inserted and is disrupting the
     operation of Fossil.

  *  A legitimate legal request was received requiring content to
     be removed. This would most likely be related to the accidental 
     intellectual property error or spam cases listed above. Some countries 
     recognise software patents, and so allow legal claims targetting code 
     commits. Some countries can require publicly-available encryption 
     software to be taken down if it is committed to the DAG without 
     the correct government authorisation.

<h2>Alternatives</h2>

All of these are rare cases: Fossil is [./antibot.wiki | designed to
foil spammers up front], legally problematic check-ins should range from
rare to nonexistent, and you have to go way out of your way to force
Fossil to insert bad control artifacts. Therefore, before we get to

    bad check-in <tt>abcd1234</tt>. You then fix up any merge conflicts,
    build, test, etc., then check the reverting change into the
    repository. Again, nothing is actually deleted; you're just adding
    more information to the repository which corrects a prior
    check-in.</p></li>
</ul>

<h2>Exception: Non-versioned Content</h2>

It is normal and expected to delete data which is not versioned, such as
usernames and passwords in the user table. The [/help/scrub|fossil scrub]
command will remove all sensitive non-versioned data from a respository.

The scrub command will remove user 'bertina', along with their password,
any supplied IP address, any concealed email address etc. However, in the 
DAG, commits by 'bertina' will continue to be visible unchanged even though
there is no longer any such user in Fossil.

<h2>Shunning</h2>

Fossil provides a mechanism called "shunning" for removing content from
a repository.

Every Fossil repository maintains a list of the hash names of