Fossil

  td, th {
    padding: 0.4em;
  }
</style>

<p>Here we document each currently-defined user capability character in
more detail than the brief summary on the <a
href="/setup_ucap_list">“key� page</a> in the Fossil user editor. Each
row gives the capability letter used in the Fossil user editor followed
by the C code’s name for that cap within the <tt>FossilUserPerms</tt>
object, so you can use this reference both from the UI down and from the
C code up.</p>

<p>The <a href="https://en.wikipedia.org/wiki/Mnemonic">mnemonics</a>
given here vary from obviously-correct to <i>post facto</i>
rationalizations to the outright fanciful. To <a
href="./impl.md#choices">some extent</a>, this is unavoidable.</p>

    <th>Admin</th>
    <td>
      Admin users have <em>all</em> of the capabilities below except for
      <a href="#s">setup</a>, <a herf="#x">Private</a>, and <a href="#y">WrUnver</a>.
      See <a href="admin-v-setup.md">Admin vs.  Setup</a> for a more
      nuanced discussion.  Mnemonic: <b>a</b>dministrate.
    </td>
  </tr>

  <tr id="b">
    <th>b</th>
    <th>Attach</th>
    <td>
      Add attachments to wiki articles or tickets.  Mnemonics: <b>b</b>ind,
      <b>b</b>utton, <b>b</b>ond, or <b>b</b>olt.
    </td>
  </tr>

  <tr id="c">
    <th>c</th>
    <th>ApndTkt</th>
    <td>
      Append comments to existing tickets. Mnemonic: <b>c</b>omment.
    </td>
  </tr>

  <tr id="d">
    <th>d</th>
    <th>Delete</th>
    <td>
      Delete wiki articles or tickets. Mnemonic: <b>d</b>elete.
    </td>
  </tr>

  <tr id="e">
    <th>e</th>
    <th>RdAddr</th>
    <td>
      View <a
      href="https://en.wikipedia.org/wiki/Personal_data">personal
      identifying information</a> (PII) about other users such as email
      addresses. Mnemonics: show <b>e</b>mail addresses; or
      <b>E</b>urope, home of <a
      href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation">GDPR</a>.
    </td>
  </tr>

  <tr id="f">
    <th>f</th>
    <th>NewWiki</th>
    <td>
      Create new wiki articles. Mnemonic: <b>f</b>ast, English
      translation of the Hawaiian word <a
      href="https://en.wikipedia.org/wiki/History_of_wikis#WikiWikiWeb,_the_first_wiki"><i>wiki</i></a>.
    </td>
  </tr> 

  <tr id="g">
    <th>g</th>
    <th>Clone</th>
    <td>
      Clone the repository. Note that this is distinct from <a
      href="#o">check-out capability, <b>o</b></a>. Mnemonic:
      <b>g</b>et.
    </td>
  </tr>

  <tr id="h">
    <th>h</th>
    <th>Hyperlink</th>
    <td>
      Get hyperlinks in generated HTML which link you to other parts of
      the repository. This capability exists so we can deny it to the
      “nobody� category, to <a href="../antibot.wiki">prevent bots from
      wandering around aimlessly</a> in the site’s hyperlink web, <a
      href="../loadmgmt.md">chewing up server resources</a> to little
      good purpose. Mnemonic: <b>h</b>yperlink.
    </td>
  </tr>

  <tr id="i">
    <th>i</th>
    <th>Write</th>
    <td>
      Check changes into the repository. Note that a lack of this
      capability does not prevent you from checking changes into your
      local clone, only from syncing those changes up to the parent
      repo, and then <a href="./basics.md#webonly">only over HTTP</a>.
      Granting this capability also grants <b>o (Read)</b>  Mnemonics:
      <b>i</b>nput, check <b>i</b>n changes.
    </td>
  </tr>

  <tr id="j">
    <th>j</th>
    <th>RdWiki</th>
    <td>
      View wiki articles. Mnemonic: in<b>j</b>est page content.  (All
      right, you critics, you do better, then.)
    </td>
  </tr>

  <tr id="k">
    <th>k</th>
    <th>WrWiki</th>
    <td>
      Edit wiki articles. Granting this capability also grants <a
      href="#j"><b>RdWiki</b></a> and <a href="#m"><b>ApndWiki</b></a>,
      but it does <em>not</em> grant <a href="#f"><b>NewWiki</b></a>!
      Mnemonic: <b>k</b>ontribute.
    </td>
  </tr>

  <tr id="l">
    <th>l</th>
    <th>ModWiki</th>
    <td>
      Moderate <a href="#m">wiki article appends</a>. Appends do not get
      saved permanently to the receiving repo’s block chain until <a
      href="#s">Setup</a> or someone with this cap approves it.
      Mnemonic: a<b>l</b>low.
    </td>
  </tr>

  <tr id="m">
    <th>m</th>
    <th>ApndWiki</th>
    <td>
      Append content to existing wiki articles.  Mnemonic: a<b>m</b>end
      wiki
    </td>
  </tr>

  <tr id="n">
    <th>n</th>
    <th>NewTkt</th>
    <td>
      File new tickets. Mnemonic: <b>n</b>ew ticket.
    </td>
  </tr>

  <tr id="o">
    <th>o</th>
    <th>Read</th>
    <td>
      Read repository content from a remote Fossil instance over
      HTTP. See <a href="index.md#read-v-clone">Reading vs.
      Cloning</a>. Mnemonic: check <b>o</b>ut remote repo contents.
    </td>
  </tr>

  <tr id="p">
    <th>p</th>
    <th>Password</th>
    <td>
      Change one’s own password. Mnemonic: <b>p</b>assword.
    </td>
  </tr>

  <tr id="q">
    <th>q</th>
    <th>ModTkt</th>
    <td>
      Moderate tickets: delete comments appended to tickets. Mnemonic:
      <b>q</b>uash noise commentary.
    </td>
  </tr>

  <tr id="r">
    <th>r</th>
    <th>RdTkt</th>
    <td>
      View existing tickets. Mnemonic: <b>r</b>ead tickets.
    </td>
  </tr>

  <tr id="s">
    <th>s</th>
    <th>Setup</th>
    <td>
      The <a href="./admin-v-setup.md#apsu">all-powerful Setup user</a>.
      Mnemonics: <b>s</b>etup or <b>s</b>uperuser.
    </td>
  </tr>

  <tr id="t">
    <th>t</th>
    <th>TktFmt</th>
    <td>
      Create new ticket report formats. Note that although this allows
      the user to provide SQL code to be run in the server’s context,
      and this capability is given to the untrusted “anonymous� user
      category by default, this is a safe capability to give to users
      because it is internally restricted to read-only queries on the
      tickets table only. (This restriction is done with a SQLite
      authorization hook, not by any method so weak as SQL text
      filtering.) Mnemonic: new <b>t</b>icket report.
    </td>
  </tr>

  <tr id="u">
    <th>u</th>
    <th>n/a</th>
    <td>
      Inherit all capabilities of the “reader� user category; does not
      have a dedicated flag internally within Fossil. Mnemonic:
      <a href="./index.md#ucat"><b>u</b>ser</a>
    </td>
  </tr>

  <tr id="v">
    <th>v</th>
    <th>n/a</th>
    <td>
      Inherit all capabilities of the “developer� user category; does
      not have a dedicated flag internally within Fossil.  Mnemonic:
      de<b>v</b>eloper.
    </td>
  </tr>

  <tr id="w">
    <th>w</th>
    <th>WrTkt</th>
    <td>
      Edit existing tickets. Granting this capability also grants <a
      href="#r"><b>RdTkt</b></a>, <a href="#c"><b>ApndTkt</b></a>, and
      <a href="#n"><b>NewTkt</b></a>. Mnemonic: <b>w</b>rite to ticket.
    </td>
  </tr>

  <tr id="x">
    <th>x</th>
    <th>Private</th>
    <td>
      Push or pull <a href="../private.wiki">private branches</a>.
      Mnemonic: e<b>x</b>clusivity; “x� connotes unknown material in
      many Western languages due to its <a
      href="https://en.wikipedia.org/wiki/La_Géométrie#The_text">traditional
      use in mathematics</a>.
    </td>
  </tr>

  <tr id="y">
    <th>y</th>
    <th>WrUnver</th>
    <td>
      Push <a href="../unvers.wiki">unversioned content</a>. Mnemonic:
      <b>y</b>ield, <a href="https://en.wiktionary.org/wiki/yield">sense
      4</a>: “hand over.�
    </td>
  </tr>

  <tr id="z">
    <th>z</th>
    <th>Zip</th>
    <td>
      Pull archives of particular repository versions via <a
      href="/help?cmd=/zip"><tt>/zip</tt></a>, <a
      href="/help?cmd=/tarball"><tt>/tarball</tt></a>, and <a
      href="/help?cmd=/sqlar"><tt>/sqlar</tt></a> URLs. This is an
      expensive capability to grant, because creating such archives can
      put a large load on <a href="../server/">a Fossil server</a> which
      you may then need to <a href="../loadmgmt.md">manage</a>.
      Mnemonic: <b>z</b>ip file download.
    </td>
  </tr>

  <tr id="2">
    <th>2</th>
    <th>RdForum</th>
    <td>
      Read <a href="../forum.wiki">forum posts</a> by other users.
      Mnemonic: from thee <b>2</b> me.
    </td>
  </tr>

  <tr id="3">
    <th>3</th>
    <th>WrForum</th>
    <td>
      Create new forum threads, reply to threads created by others, and
      edit one’s own posts. New posts are <a
      href="../forum.wiki#moderation">held for moderation</a> and do
      not appear in repo clones or syncs. Granting this capability also
      grants <a href="#2"><b>RdForum</b></a>.   Mnemonic: post for
      <b>3</b> audiences: me, <a href="#5">the mods</a>, and <a
      href="https://en.wikipedia.org/wiki/The_Man">the Man</a>.
    </td>
  </tr>

  <tr id="4">
    <th>4</th>
    <th>WrTForum</th>
    <td>
      Extends <a href="#3"><b>WrForum</b></a>, bypassing the moderation
      and sync restrictions. Mnemonic: post <b>4</b> immediate release.
    </td>
  </tr>

  <tr id="5">
    <th>5</th>
    <th>ModForum</th>
    <td>
      <a href="../forum.wiki#moderation">Moderate forum posts</a>.
      Granting this capability also grants <a
      href="#4"><b>WrTForum</b></a> and <a href="#2"><b>RdForum</b></a>,
      so a user with this cap never has to moderate their own posts.
      Mnemonic: “May I have <b>5</b> seconds of your time, honored
      Gatekeeper?�
    </td>
  </tr>

  <tr id="6">
    <th>6</th>
    <th>AdminForum</th>
    <td>
      Users with this capability see a checkbox on unmoderated forum
      posts labeled “Trust user X so that future posts by user X do not
      require moderation.� Checking that box and then clicking the
      moderator-only “Approve� button on that post grants <a
      href="#4"><b>WrTForum</b></a> capability to that post’s author.
      There is currently no UI for a user with this cap to
      <em>revoke</em> trust from a user once it is granted; only <a
      href="#a"><b>Admin</b></a> and <a href="#s"><b>Setup</b></a> can
      currently revoke granted caps.  Granting this capability also
      grants <a href="#5"><b>ModForum</b></a> and those it in turn
      grants.  Mnemonic: “I’m <b>6</b> [sick] of hitting Approve on your
      posts!�
    </td>
  </tr>

  <tr id="7">
    <th>7</th>
    <th>EmailAlert</th>
    <td>
      User can sign up for <a href="../alerts.md">email alerts</a>.
      Mnemonic: <a href="https://en.wikipedia.org/wiki/Heaven_Can_Wait">Seven can
      wait</a>, I’ve got email to read now.
    </td>
  </tr>

  <tr id="A">
    <th>A</th>
    <th>Announce</th>
    <td>
      Send email announcements to users <a href="#7">signed up to
      receive them</a>. Mnemonic: <b>a</b>nnounce.
    </td>
  </tr>

  <tr id="D">
    <th>D</th>
    <th>Debug</th>
    <td>
      Enable debugging features. Mnemonic: <b>d</b>ebug.
    </td>
  </tr>
</table>

<hr/>

<p id="backlink"><a href="./"><em>Back to Administering User
Capabilities</em></a></p>

In the second through the fourth forms,
the space between the day and the year can optionally be
replaced by an uppercase <b>T</b> and the entire timestamp can
optionally be followed by "<b>z</b>" or "<b>Z</b>".  In the fourth
form with fractional seconds, any number of digits may follow the
decimal point, though due to precision limits only the first three
digits will be significant.  The final three pure-digit forms
without punctuation are only valid if the number they encode is
not also the prefix of an artifact hash.

In its default configuration, Fossil interprets and displays all dates
in Universal Coordinated Time (UTC).  This tends to work the best for
distributed projects where participants are scattered around the globe.
But there is an option on the Admin/Timeline page of the web-interface to

Fossil comes with multiple built-in skins.  If the default skin does not
suite your tastes, perhaps one of the other built-in skins will work better.
If nothing else, the built-in skins can serve as examples or baselines that
you can use to develop your own custom skin.

The sources to these built-ins can
be found in the Fossil source tree under the skins/ folder.  The
[skins/](/dir?ci=trunk&name=skins)
folder contains a separate subfolder for each built-in skin, with each
subfolders holding at least these five files:

   * css.txt
   * details.txt
   * footer.txt

to close out the generated HTML:

        </body>
        </html>

## <a name="override"></a>Overriding the HTML Header and Footer

Notice that the `<html>`, `<head>`, and opening `<body>`
elements at the beginning of the document,
and the closing `</body>` and `</html>` elements at the end are automatically
generated by Fossil.  This is recommended.

However, for maximum design flexibility, Fossil allows those elements to be
supplied as part of the configurable Content Header and Content Footer.
If the Content Header contains the text "`<body`", then Fossil assumes that

<dt><b>footer.txt</b> and <b>header.txt</b></dt><dd>

<p>The footer.txt and header.txt files contain the Content Footer
and Content Header respectively.  Of these, the Content Header is
the most important, as it contains the markup used to generate
the banner and menu bar for each page.

<p>Both the footer.txt and header.txt file are
[processed using TH1](#headfoot) prior to being output as
part of the overall web page.</dd>

<dt><b>js.txt</b></dt><dd>

<p>The js.txt file is intended to be javascript.  The complete
text of this javascript is typically inserted into the Content Footer
by this part of the "footer.txt" file:

<p>This document describes the delta-encoding format used by Fossil.
The intended audience is developers working on either
<a href="index.wiki">Fossil</a> itself, or on tools compatible with
Fossil. Understanding of this document is <em>not</em> required for
ordinary users of Fossil.  This document is an implementation detail.</p>

<p>This document only describes the delta file format.  A
[./delta_encoder_algorithm.wiki|separate document] describes one possible
algorithm for generating deltas in this format.</p>

<h2>1.1 Sample Software And Analysis Tools</h2>

<p>The core routines used to generate and apply deltas in this format
are contained in the [../src/delta.c|delta.c] source file.  Interface

the check-in, or it might be the name of a branch or tag, or it might
be a timestamp.  See the [./checkin_names.wiki|check-in name documentation]
for more possibilities and examples.  The <i>&lt;version&gt;</i> can
also be the special identifier "<b>ckout</b>".
The "<b>ckout</b>" keywords means to
pull the documentation file from the local source tree on disk, not
from the any check-in.  The "<b>ckout</b>" keyword
only works when you start your server using the
"[/help?cmd=server|fossil server]" or "[/help?cmd=ui|fossil ui]"
commands.  The "/doc/ckout" URL is intended to show a preview of
the documentation you are currently but have not yet you checked in.

Finally, the <i>&lt;filename&gt;</i> element of the URL is the
pathname of the documentation file relative to the root of the source
tree.

<h1>2.0 Server-Side Text Substitution</h1>

Fossil can do a few types of substitution of server-side information
into the embedded document.

<h2>2.1 "$ROOT" In HTML and Markdown Hyperlinks</h2>

Hyperlinks in Markdown and HTML embedded documents can reference
the root of the Fossil repository using the special text "$ROOT"
at the beginning of a URL. For example, a Markdown hyperlink to
the Markdown formatting rules might be
written in the embedded document like this:

<nowiki><pre>
        [Markdown formatting rules]($ROOT/wiki_rules)

Fossil will substitute the value of [./th1.md | TH1 expressions] within
<tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have
configured it with the <tt>--with-th1-docs</tt> option, which is
disabled by default.

Since TH1 is a full scripting language, this feature essential grants
the ability to execute code on the server to any with check-in
privilege for the project.
This is a security risk that needs to be carefully managed.
The feature is off by default.
Administrators should understand and carefully assess the risks
before enabling the use of TH1 within embedded documentation.

of text in the wiki page.  That text follows the newline character
that terminates the <b>W</b> card.  The wiki text is always followed by one
extra newline.

The <b>C</b> card on a wiki page is optional.  The argument is a comment
that explains why the changes was made.  The ability to have a <b>C</b>
card on a wiki page artifact was added on 2019-12-02 at the suggestion
of user George Krivov and is not currently used or generated by the
implementation. Older versions of Fossil will reject a wiki-page
artifact that includes a <b>C</b> card.

An example wiki artifact can be seen
[/artifact?name=7b2f5fd0e0&txt=1 | here].

<a name="tktchng"></a>

</table></blockquote>

<h3 id="features">2.1 Featureful</h3>

Git provides file versioning services only, whereas Fossil adds
an integrated [./wikitheory.wiki | wiki],
[./bugtheory.wiki | ticketing &amp; bug tracking],
[./embeddeddoc.wiki | embedded documentation],
[./event.wiki | technical notes], and a [./forum.wiki | web forum],
all within a single nicely-designed [./customskin.md|skinnable] web
[/help?cmd=ui|UI],
protected by [./caps/ | a fine-grained role-based
access control system].
These additional capabilities are available for Git as 3rd-party
add-ons, but with Fossil they are integrated into

the two systems.  Git focuses on individual branches, because that
is exactly what you want for a highly-distributed bazaar-style project
such as Linux.  Linus Torvalds does not want to see every check-in
by every contributor to Linux, as such extreme visibility does not scale
well.  But Fossil was written for the cathedral-style SQLite project
with just a handful of active committers.  Seeing all
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more
tightly focused and cohesive implementation.


<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>

Because Git commingles the repository data with the initial checkout of
that repository, the default mode of operation in Git is to stick to that

in which every commit is tested first. We think this is an inherently
good thing.

Incidentally, this is a good example of Git's messy command design.
These three commands:

<pre>
    $ git merge HASH
    $ git cherry-pick HASH
    $ git revert HASH
</pre>

...are all the same command in Fossil:

<pre>
    $ fossil merge HASH

Fossil 2.10 changed the default hash policy to "sha3" mode even for
legacy repositories, so if you
upgrade to the latest version of Fossil, all of your new artifacts will
use a SHA3 hash.  Legacy SHA1 artifacts continue to use their original
names, but new artifacts will use SHA3 names. You might not even notice
this automatic change over to stronger hashes.

We decided to make the change to pure SHA3 since the last known distributor
of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019
by Debian 10, which included Fossil 2.8. All other known sources of
Fossil 1.x binaries upgraded well before that point.

in the Fossil repository database file.

Storing pre-compressed data files in a Fossil repository defeats both of
these space-saving measures:

1.  Binary data compression algorithms — whether lossless as with zlib
    or lossy as with JPEG — turn the file data into [pseudorandom
    noise][prn].²

    Typical data compression algorithms are not [hash functions][hf],
    where the goal is that a change to each bit in the input has a
    statistically even chance of changing every bit in the output, but
    because they do approach that pathological condition, pre-compressed
    data tends to defeat Fossil’s delta compression algorithm, there
    being so little correlation between two different outputs from the
    binary data compression algorithm.

  *   Site-map:  [](../../../../sitemap)

  *   Windows CGI: [](../server/windows/cgi.md)

## The Magic $ROOT Path Prefix

In text of the form `href="$ROOT/..."` in the HTML that markdown
generates, the $ROOT is replaced by the complete URI for the root
of the document tree.
Note that the $ROOT translation only occurs within the `<a href="...">`
element, not within the text of the hyperlink.  So you should see the
$ROOT text on this page, but if you mouse-over the hyperlink the $ROOT
value should have been expanded to the actual document root.

  *   Timeline: []($ROOT/timeline)

## (3) Named Branches

Git has only limited support for named branches.  Git identifies the head
check-in of each branch.  Depending on the check-in graph topology, this
is sufficient to infer the branch for many historical check-ins as well.
However, complex histories with lots of cross-merging
can lead to ambiguities.  Fossil keeps
track of historical branch names unambiguously.
But the extra details about branch names that Fossil keeps
at hand cannot be exported to Git.

## (4) Non-unique Tags

Git requires tags to be unique.  Each tag must refer to exactly one
check-in.  Fossil does not have this restriction, and so it is common
in Fossil to tag multiple check-ins with the same name.  For example,
it is common in Fossil to tag every release check-in with the "release"
tag, so that all historical releases can be found all at once.
([example](/timeline?t=release))

Git does not allow this.  The "release" tag must refer to just one
check-in.  The work-around is that the non-unique tag in the Git export is
made to refer to only the most recent check-in with that tag.

## (5) Amendments To Check-ins

Check-ins are immutable in both Fossil and Git.
However, Fossil has a mechanism by which tags can be added
its blockchain to provide after-the-fact corrections to prior check-ins.

      consider using <code>../git-mirror</code> to place the Git export
      mirror alongside them, for example.  Fossil will create this
      directory if necessary.  This directory will become a Git
      repository that holds a translation of your Fossil repository.

<p>   The <code>--autopush</code> option tells Fossil that you want to
      push the Git translation up to GitHub every time it is updated.

<p>   The URL parameter is the same as the one GitHub gave you, but with
      your GitHub <font color="orange">username</font> and <font
      color="red">password</font> added.

<p>   If your GitHub account uses two-factor authentication (2FA), you
      will have to <a href="https://github.com/settings/tokens">generate
      a personal access token</a> and use that in place of your actual
      password in the URL. This token should have “repo” scope enabled,
      only.

<p>   You can also run the command above outside of any open checkout of

     features of Fossil that make it so convenient to use, so those other
     elements cannot be mirrored in Git.

  *  In Git, all tags must be unique.  If your Fossil repository has the
     same tag on two or more check-ins, the tag will only be preserved on
     the chronologically newest check-in.

  *  There is a
     [long list of restrictions](https://git-scm.com/docs/git-check-ref-format)
     on tag and branch names in Git.  If any of your Fossil tag or branch names
     violate these rules, then the names are translated prior to being exported
     to Git.  The translation usually involves converting the offending characters
     into underscores.

<a name='ex1'></a>

>
<https://github.com/sqlite/sqlite>

The Fossil source repositories for these mirrors are at
<https://www2.fossil-scm.org/fossil> and <https://www2.sqlite.org/src>,
respectively.  Both repositories are hosted on the same VM at
[Linode](https://www.linode.com).  On that machine, there is a
[cron job](https://linux.die.net/man/8/cron)
that runs at 17 minutes after the hour, every hour that does:

>
    /usr/bin/fossil sync -u -R /home/www/fossil/fossil.fossil
    /usr/bin/fossil sync -R /home/www/fossil/sqlite.fossil
    /usr/bin/fossil git export -R /home/www/fossil/fossil.fossil
    /usr/bin/fossil git export -R /home/www/fossil/sqlite.fossil

The initial two "sync" commands pull in changes from the primary
Fossil repositories for Fossil and SQLite.  The last two lines
export the changes to Git and push the results up to GitHub.

# Rebase Considered Harmful

Fossil deliberately omits a "rebase" command because the original
designer of Fossil (and [original author][vhist] of this article) considers rebase to be
an anti-pattern to be avoided. This article attempts to
explain that point of view.

[vhist]: /finfo?name=www/rebaseharm.md&ubg

## 1.0 Rebasing is dangerous

Most people, even strident advocates of rebase, agree that rebase can
cause problems when misused. The Git rebase documentation talks about the
[golden rule of rebasing][golden]: never rebase on a public
branch.  Horror stories of misused rebase abound, and the rebase
documentation devotes considerable space toward explaining how to
recover from rebase errors and/or misuse.

## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities

Sometimes sharp and dangerous tools are justified,
because they accomplish things that cannot be
done otherwise, or at least cannot be done easily.
Rebase does not fall into that category,
because it provides no new capabilities.

### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted

A rebase is really nothing more than a merge (or a series of merges)
that deliberately forgets one of the parents of each merge step.
To help illustrate this fact,
consider the first rebase example from the
[Git documentation][gitrebase].  The merge looks like this:

![merge case](./rebase01.svg)

And the rebase looks like this:

![rebase case](./rebase02.svg)

As the [Git documentation][gitrebase] points out, check-ins C4\' and C5
are identical.  The only difference between C4\' and C5 is that C5
records the fact that C4 is its merge parent but C4\' does not.

Thus, a rebase is just a merge that forgets where it came from.

The Git documentation acknowledges this fact (in so many words) and
justifies it by saying "rebasing makes for a cleaner history."  I read
that sentence as a tacit admission that the Git history display
capabilities are weak and need active assistance from the user to
keep things manageable.
Surely a better approach is to record
the complete ancestry of every check-in but then fix the tool to show
a "clean" history in those instances where a simplified display is
desirable and edifying, but retain the option to show the real,
complete, messy history for cases where detail and accuracy are more
important.

So, another way of thinking about rebase is that it is a kind of
merge that intentionally forgets some details in order to
not overwhelm the weak history display mechanisms available in Git.
Wouldn't it be better, less error-prone, and easier on users
to enhance the history display mechanisms in Git so that rebasing
for a clean, linear history became unnecessary?

### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs

Another argument, often cited, is that rebasing a feature branch
allows one to see just the changes in the feature branch without
the concurrent changes in the main line of development.
Consider a hypothetical case:

![unmerged feature branch](./rebase03.svg)

In the above, a feature branch consisting of check-ins C3 and C5 is
run concurrently with the main line in check-ins C4 and C6.  Advocates
for rebase say that you should rebase the feature branch to the tip

Because Fossil purposefully lacks rebase, the closest you can get to this same check-in
history is the following merge:

![merged feature branch](./rebase05.svg)

Check-ins C5\' and C7 check-ins hold identical code.  The only
difference is in their history.

The argument from rebase advocates
is that with merge it is difficult to see only the changes associated
with the feature branch without the commingled mainline changes.
In other words, diff(C2,C7) shows changes from both the feature
branch and from the mainline, whereas in the rebase case
diff(C6,C5\') shows only the feature branch changes.

</table></center>

Remember: C7 and C5\' are bit-for-bit identical, so the output of the
diff is not determined by whether you select C7 or C5\' as the target
of the diff, but rather by your choice of the diff source, C2 or C6.

So, to help with the problem of viewing changes associated with a feature
branch, perhaps what is needed is not rebase but rather better tools to
help users identify an appropriate baseline for their diffs.

## <a name="siloing"></a>3.0 Rebase encourages siloed development

The [golden rule of rebasing][golden] is that you should never do it
on public branches, so if you are using rebase as intended, that means
you are keeping private branches.  Or, to put it another way, you are

The [Git rebase documentation][gitrebase] admits as much.  They acknowledge
that when you view a repository as record of what actually happened,
doing a rebase is "blasphemous" and "you're _lying_ about what
actually happened", but then goes on to justify rebase as follows:

>
_"The opposing point of view is that the commit history is the **story of
how your project was made.** You wouldn't publish the first draft of a
book, and the manual for how to maintain your software deserves careful
editing. This is the camp that uses tools like rebase and filter-branch
to tell the story in the way that's best for future readers."_

This counter-argument assumes you must
change history in order to enhance readability, which is not true.

In fairness to the Git documentation authors, changing the
project history appears to be the only way to make editorial

not in theory.

Unfortunately, Git does not currently provide the ability to add
corrections or clarifications or supplimental notes to historical check-ins.
Hence, once again,
rebase can be seen as an attempt to work around limitations
of Git.  Git could be enhanced to support editorial changes
to check-ins.
Wouldn't it be better to fix the version control tool
rather than requiring users to fabricate a fictitious project history?

## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information

One of the oft-cited advantages of rebasing in Git is that it lets you
collapse multiple check-ins down to a single check-in to make the

There are several key differences between “`ui`” and “`server`”:

*   “`ui`” always binds the server to the loopback IP address (127.0.0.1)
    so that it cannot serve to other machines.

*   Anyone who visits this URL is treated as the all-powerful Setup
    user, which is why the first difference exists.

*   “`ui`” launches a local web browser pointed at this URL.

You can omit the _REPOSITORY_ argument if you run one of the above
commands from within a Fossil checkout directory to serve that
repository:

        $ fossil ui          # or...

<h2>No Server Required</h2>

<p>Fossil does not require a central server, but <a
href="whyuseaserver.wiki">a server can be useful</a>.</p>

<p>A Fossil server does not require much memory, CPU, or disk space
and can run comfortably on a generic $5/month virtual host
or on a small device like a Raspberry Pi, or it can co-exist
on a host running other services without getting in the way.

<p>This article is a quick-reference guide for setting up your own
Fossil server, with links to more detailed instructions specific to
particular systems, should you want extra help.</p>


<h2 id="prep">Repository Prep</h2>

<p>Prior to serving a Fossil repository to others, consider running <a
href="$ROOT/help?cmd=ui"><tt>fossil ui</tt></a> locally and taking these
minimum recommended preparation steps:</p>

<ol>
  <li><p>Fossil creates only one user in a <a
  href="$ROOT/help?cmd=new">new repository</a> and gives it the <a
  href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>.
  The 10-digit random password generated for that user is fairly strong
  against remote attack, even without explicit password guess rate
  limiting, but because that user has so much power, you may want to
  give it a much stronger password under Admin → Users.</a></li>

  <li><p>Run the Admin → Security-Audit tool to verify that other
  security-related permissions and settings are as you want them.
  Consider clicking the “Take it private� link on that page to lock down
  the security on that site to a level appropriate to a private
  repository, even if you will eventually want some public service. It's
  better to start from a secure position and open up service
  feature-by-feature as necessary than it is to start from a fully open
  position and lock down features one by one to achieve a secure
  stance.</p></li>
</ol>

can be configured to invoke the the
<a href="$ROOT/help?cmd=http"><tt>fossil http</tt></a> command to handle
each incoming HTTP request.  The "<tt>fossil http</tt>" command reads
the HTTP request off of standard input, computes an appropriate
reply, and writes the reply on standard output.  There is a separate
invocation of the "<tt>fossil http</tt>" command for each HTTP request.
The socket listener daemon takes care of relaying content to and from
the client, and (in the case of <a href="any/stunnel.md">stunnel</a>)
handling TLS decryption and encryption.

<h3>Stand-alone HTTP Server</h3>

<p>This is the <a href="any/none.md">easiest method</a>.
A stand-alone server uses the
<a href="$ROOT/help?cmd=server"><tt>fossil server</tt></a> command to run a

sub-articles. Some of these are generic, while others depend on
particular operating systems or front-end software:</p>

<div id="tutpick" class="show"></div>

<table style="margin-left: 6em;">
    <tr>
        <th class="host">⇩ OS / Method ⇨</th>
        <th class="fep">direct</th>
        <th class="fep">inetd</th>
        <th class="fep">stunnel</th>
        <th class="fep">CGI</th>
        <th class="fep">SCGI</th>
        <th class="fep">althttpd</th>
        <th class="fep">proxy</th>
        <th class="fep">service</th>
    </tr>

    <tr>
        <th class="host">Any</th>
        <td class="doc"><a href="any/none.md">✅</a></td>
        <td class="doc"><a href="any/inetd.md">✅</a></td>
        <td class="doc"><a href="any/stunnel.md">✅</a></td>
        <td class="doc"><a href="any/cgi.md">✅</a></td>
        <td class="doc"><a href="any/scgi.md">✅</a></td>
        <td class="doc"><a href="any/althttpd.md">✅</a></td>
        <td class="doc">�</td>
        <td class="doc">�</td>
    </tr>

    <tr>
        <th class="host">Debian/Ubuntu</th>
        <td class="doc"><a href="any/none.md">✅</a></td>
        <td class="doc"><a href="any/inetd.md">✅</a></td>
        <td class="doc"><a href="any/stunnel.md">✅</a></td>
        <td class="doc"><a href="any/cgi.md">✅</a></td>
        <td class="doc"><a href="any/scgi.md">✅</a></td>
        <td class="doc"><a href="any/althttpd.md">✅</a></td>
        <td class="doc"><a href="debian/nginx.md">✅</a></td>
        <td class="doc"><a href="debian/service.md">✅</a></td>
    </tr>

    <tr>
        <th class="host">macOS</th>
        <td class="doc"><a href="any/none.md">✅</a></td>
        <td class="doc">�</td>
        <td class="doc"><a href="any/stunnel.md">✅</a></td>
        <td class="doc"><a href="any/cgi.md">✅</a></td>
        <td class="doc"><a href="any/scgi.md">✅</a></td>
        <td class="doc"><a href="any/althttpd.md">✅</a></td>
        <td class="doc">�</td>
        <td class="doc"><a href="macos/service.md">✅</a></td>
    </tr>

    <tr>
        <th class="host">Windows</th>
        <td class="doc"><a href="windows/none.md">✅</a></td>
        <td class="doc">�</td>
        <td class="doc"><a href="windows/stunnel.md">✅</a></td>
        <td class="doc"><a href="windows/cgi.md">✅</a></td>
        <td class="doc">�</td>
        <td class="doc">�</td>
        <td class="doc"><a href="windows/iis.md">✅</a></td>
        <td class="doc"><a href="windows/service.md">✅</a></td>
    </tr>
</table>

<p>Where there is a check mark in the "<b>Any</b>" row, the method for that is
generic enough that it works across OSes that Fossil is known to work
on. The check marks below that usually just link to this generic
documentation.</p>

<p>The method in the "<b>proxy</b>" column is for the platform's default
web server configured as a <a
href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> for
Fossil's built-in HTTP server: <a href="debian/nginx.md">nginx</a>, <a
href="windows/iis.md">IIS</a>, Apache, etc.</p>

<p>We welcome <a href="../contribute.wiki">contributions</a> to fill gaps
(<font size="-2">�</font>) in the table above.</p>
</noscript>


<h2 id="postsetup">Post-Activation Configuration</h2>

<p>After the server is up and running, log into it as the Setup user and
visit the Admin menu to finish configuring that repository for

  prior to setting up the server.</p></li>

  <li><p>Modify the repository's look and feel by <a
  href="../customskin.md">customizing the skin</a>.</p></li>

  <li><p>If the repository includes <a
  href="../embeddeddoc.wiki">embedded documentation</a>, consider
  activating the search feature (Admin → Search) so that visitors can do
  full-text search on your documentation.</p></li>

  <li><p>Now that others can be making changes to the repository,
  consider monitoring them via <a href="../alerts.md">email alerts</a>
  or the <a href="$ROOT/help?cmd=/timeline.rss">timeline RSS
  feed</a>.</p></li>

  <li><p>Turn on the various logging features.</p></li>
</ol>

<p>Reload the Admin → Security-Audit page occasionally during this
process to double check that you have not mistakenly configured the
server in a way that might expose information that you want to keep
private.</p>


<h2 id="more">Further Details</h2>

<title>Benefits Of A Fossil Server</title>

<h2>No Server Required</h2>

Fossil does not require a central server.
Data sharing and synchronization can be entirely peer-to-peer.
Fossil uses
[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types]
to ensure that (in the limit) all participating peers see the same content.

<h2>But, A Server Can Be Useful</h2>

Fossil does not require a server, but a server can be very useful.
Here are a few reasons to set up a Fossil server for your project:

  1.  <b>A server works as a complete project website.</b><p>
      Fossil does more than just version control.  It also supports
      [../tickets.wiki|trouble-tickets],
      [../wikitheory.wiki|wiki], and a [../forum.wiki|forum].
      The [../embeddeddoc.wiki|embedded documentation]
      feature provides  a great mechanism for providing project documentation.
      The [../unvers.wiki|unversioned files] feature is a convenient way
      to host builds and downloads on the project website.

  2.  <b>A server gives developers a common point of rendezvous for

1.  Start “Server Manager”
2.  Tell it you want to “Add roles and features”
3.  Select “Role-based or feature-based installation”
4.  Select your local server
5.  In the Server Roles section, enable “Web Server (IIS)”

### Windows

1.  Open Control Panel
2.  Go to “Programs”
3.  Select “Turn Windows features on or off” in the left-side pane
4.  In the “Windows Features” dialog, enable “Internet Information
    Services”

<title>CGI Server Extensions</title>

<h2>1.0 Introduction</h2>

If you have a [./server/|Fossil server] for your project,
you can add [https://en.wikipedia.org/wiki/Common_Gateway_Interface|CGI]
extensions to that server.  These extensions work like
any other CGI program, except that they also have access to the Fossil
login information and can (optionally) leverage the "skins" of Fossil
so that they appear to be more tightly integrated into the project.

An example of where this is useful is the
[https://sqlite.org/src/ext/checklist|checklist application] on
the [https://sqlite.org/|SQLite] project.  The checklist
helps the SQLite developers track which release tests have passed,
or failed, or are still to be done.  The checklist program began as a
stand-alone CGI which kept its own private user database and implemented
its own permissions and login system and provided its own CSS.  By
converting checklist into a Fossil extension, the same login that works
for the [https://sqlite.org/src|main SQLite source repository] also works
for the checklist.  Permission to change elements of the checklist
is tied on permission to check-in to the main source repository.  And
the standard Fossil header menu and footer appear on each page of
the checklist.

<h2>2.0 How It Works</h2>

CGI Extensions are disabled by default.
An administrator activates the CGI extension mechanism by specifying
an "Extension Root Directory" or "extroot" as part of the server setup.
If the Fossil server is itself run as
[./server/any/cgi.md|CGI], then add a line to the
[./cgi.wiki#extroot|CGI script file] that says:

<blockquote><pre>
extroot: <i>DIRECTORY</i>
</pre></blockquote>

Or, if the Fossil server is being run using the
"[./server/any/none.md|fossil server]" o
"[./server/any/none.md|fossil ui]" or
"[./server/any/inetd.md|fossil http]" commands, then add an extra
"--extroot <i>DIRECTORY</i>" option to that command.

The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI.
Files in the DOCUMENT_ROOT are accessed via URLs like this:

<blockquote>
https://example-project.org/ext/<i>FILENAME</i>

they are used.
Live listings of the values of some or all of these environment variables
can be found at links like these:

  *  [https://fossil-scm.org/home/test_env]
  *  [https://sqlite.org/src/ext/checklist/top/env]

In addition to the standard CGI environment variables listed above,
Fossil adds the following:

  *  FOSSIL_CAPABILITIES
  *  FOSSIL_NONCE
  *  FOSSIL_REPOSITORY
  *  FOSSIL_URI
  *  FOSSIL_USER

The FOSSIL_USER string is the name of the logged-in user.  This variable
is missing or is an empty string if the user is not logged in.  The
FOSSIL_CAPABILITIES string is a list of
[./caps/ref.html|Fossil capabilities] that
indicate what permissions the user has on the Fossil repository.
The FOSSIL_REPOSITORY environment variable gives the filename of the
Fossil repository that is running.  The FOSSIL_URI variable shows the
prefix of the REQUEST_URI that is the Fossil CGI script, or is an
empty string if Fossil is being run by some method other than CGI.

The [https://sqlite.org/src/ext/checklist|checklist application] uses the
FOSSIL_USER environment variable to determine the name of the user and
the FOSSIL_CAPABILITIES variable to determine if the user is allowed to
mark off changes to the checklist.  Only users with check-in permission
to the Fossil repository are allowed to mark off checklist items.  That
means that the FOSSIL_CAPABILITIES string must contain the letter "i".
Search for "FOSSIL_CAPABILITIES" in the
[https://sqlite.org/src/ext/checklist/top/self|source listing] to see how
this happens.

If the CGI output is one of the forms for which Fossil inserts its own
header and footer, then the inserted header will include a
Content Security Policy (CSP) restriction on the use of javascript within
the webpage.  Any <script>...</script> elements within the
CGI output must include a nonce or else they will be suppressed by the
web browser.  The FOSSIL_NONCE variable contains the value of that nonce.
So, in other words, to get javascript to work, it must be enclosed in:

<blockquote><verbatim>
<script nonce='$FOSSIL_NONCE'>...</script>
</verbatim></blockquote>

The fields of the CGI response header can be any valid HTTP header fields.
Those that Fossil does not understand are simply relayed back to up the
line to the requester.

Fossil takes special action with some content types.  If the Content-Type
is "text/x-fossil-wiki" or "text/x-markdown" then Fossil
converts the content from [/wiki_rules|Fossil-Wiki] or
[/md_rules|Markdown] into HTML, adding its
own header and footer text according to the repository skin.  Content
of type "text/html" is normally passed straight through
unchanged.  However, if the text/html content is of the form:

<blockquote><verbatim>
<div class='fossil-doc' data-title='DOCUMENT TITLE'>
... HTML content there ...
</div>
</verbatim></blockquote>

In other words, if the outer-most markup of the HTML is a &lt;div&gt;
element with a single class of "fossil-doc",
then Fossil will adds its own header and footer to the HTML.  The
page title contained in the added header will be extracted from the
"data-title" attribute.

Except for the three cases noted above, Fossil makes no changes or
additions to the CGI-generated content.  Fossil just passes the verbatim
content back up the stack towards the requester.

itself inside a chroot jail if it can.  The sub-CGI program will also
run inside this same chroot jail.  Make sure all embedded pathnames
have been adjusted accordingly and that all resources needed by the
CGI program are available within the chroot jail.

If anything goes wrong while trying to process an /ext page, Fossil
returns a 404 Not Found error with no details.  However, if the requester
is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability
then additional diagnostic information may be included in the output.

If the /ext page has a "fossil-ext-debug=1" query parameter and if
the requester is logged in as a user with Debug privilege, then the
CGI output is returned verbatim, as text/plain and with the original
header intact.  This is useful for diagnosing problems with the
CGI script.

[/help?cmd=configuration|config pull]
commands.

<a name="crdt"></a>
<h3>1.1 Conflict-Free Replicated Datatypes</h3>

<p>The "bag of artifacts" data model used by Fossil
Fossil is apparently an implementation of a particular
[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|Conflict-Free Replicated
Datatype (CRDT)]
called a "G-Set" or "Grow-only Set".
The academic literature on CRDTs only began to appear in about 2011, and
Fossil predates that research by at least 4 years.  But it is nice to know
that theorists have now proven that the underlying data model of Fossil can
provide strongly-consistent replicas using only peer-to-peer communication

As of Fossil 2.9, the permanent HTTP-to-HTTPS redirect we enabled above
causes Fossil to remember the new URL automatically the first time it’s
redirected to it. All you need to do to switch your syncs to HTTPS is:

      $ cd ~/path/to/checkout
      $ fossil sync


## Step 7: Renewing Automatically

Now that the configuration is solid, you can renew the LE cert with the
`certbot` command from above without the `--dry-run` flag plus a restart
of nginx: