Fossil

part of the job, which can be recombined (by experts) to perform
powerful operations. Git has a lot of complexity and many dependencies,
so that most people end up installing it via some kind of package
manager, simply because the creation of complicated binary packages is
best delegated to people skilled in their creation. Normal Git users are
not expected to build Git from source and install it themselves.

Fossil is a single self-contained stand-alone executable which by default
depends only on common platform libraries. If your platform allows static
linking — not all do these days! — you can even get it down to
a single executable with no external dependencies at all. Most notably,
we deliver the official Windows builds of Fossil this way: the Zip file
contains only <tt>fossil.exe</tt>, a self-contained Fossil executable;
it is not a <tt>setup.exe</tt> style installer, it is the whole enchilada.

A typical Fossil executable is about 5&nbsp;MiB, not counting system
libraries it shares in common with Git such as OpenSSL and zlib, which
we can factor out of the discussion.

These properties allow Fossil to easily run inside a minimally configured
[https://en.wikipedia.org/wiki/Chroot|chroot jail], from a Windows memory
stick, off a Raspberry Pi with a tiny SD card, etc. To install Fossil,
one merely puts the executable somewhere in the <tt>$PATH</tt>. Fossil is

[https://fossil-scm.org/fossil/doc/trunk/www/build.wiki|straightforward
to build and install], so that many Fossil users do in fact build and
install "trunk" versions to get new features between formal releases.

Contrast a basic installation of Git, which takes up about
15&nbsp;MiB on Debian 10 across 230 files, not counting the contents of
<tt>/usr/share/doc</tt> or <tt>/usr/share/locale</tt>. If you need to
deploy to any platform where you cannot count facilities like the POSIX
shell, Perl interpreter, and Tcl/Tk platform needed to fully use Git
as part of the base platform, the full footprint of a Git installation
extends to more like 45&nbsp;MiB and thousands of files. This complicates
several common scenarios: Git for Windows, chrooted Git servers,
Docker images...

Some say that Git more closely adheres to the Unix philosophy,
summarized as "many small tools, loosely joined," but we have many
examples of other successful Unix software that violates that principle
to good effect, from Apache to Python to ZFS. We can infer from that
that this is not an absolute principle of good software design.
Sometimes "many features, tightly-coupled" works better. What actually
matters is effectiveness and efficiency. We believe Fossil achieves
this.

The above size comparisons aren't apples-to-apples anyway. We've
compared the size of Fossil with all of its [#features | many built-in
features] to a fairly minimal Git installation. You must add a lot
of third-party
software to Git to give it a Fossil-equivalent feature set. Consider
[https://about.gitlab.com/|GitLab], a third-party extension to Git
wrapping it in many features, making it roughly Fossil-equivalent,
though [https://docs.gitlab.com/ee/install/requirements.html|much more
resource hungry] and hence more costly to run than the equivalent
Fossil setup. GitLab's basic requirements are easy to accept when you're dedicating
a local rack server or blade to it, since its minimum requirements are
more or less a description of the smallest
thing you could call a "server" these days, but when you go to host that
in the cloud, you can expect to pay about 8× as much to comfortably host
GitLab as for Fossil.³ This difference is largely due to basic
technology choices: Ruby and PostgreSQL vs C and SQLite.

The Fossil project itself is [./selfhost.wiki|hosted on a very small
VPS], and we've received many reports on the Fossil forum about people
successfully hosting Fossil service on bare-bones $5/month VPS hosts,
spare Raspberry Pi boards, and other small hosts.