XDEFiANCE'e Quality Internet Shop

Fossil has inbound and outbound Git conversion features, so if you start out using one DVCS and later decide you like the other better, you can easily move your version-controlled file content.¹

In this document, we set all of that similarity and interoperability aside and focus on the important differences between the two, especially those that impact the user experience.

Keep in mind that you are reading this on a Fossil website, and though we try to be fair, the information here might be biased in favor of Fossil, if only because we spend most of our time using Fossil, not Git. Ask around for second opinions from people who have used both Fossil and Git.

If you want a more practical, less philosophical guide to moving from Git to Fossil, see our Git to Fossil Translation Guide.

Differences between Fossil and Git are summarized by the following table, with further description in the text that follows.

For instance, Fossil can do operations over all local repo clones and check-out directories with a single command. You can say “fossil all sync” on a laptop prior to taking it off the network hosting those repos, as before going on a trip. It doesn’t matter if those repos are private and restricted to your company network or public Internet-hosted repos, you get synced up with everything you need while off-network.

You get the same capability with several other Fossil sub-commands as well, such as “fossil all changes” to get a list of files that you forgot to commit prior to the end of your working day, across all repos.

Whenever Fossil is told to modify the local checkout in some destructive way (fossil rm, fossil update, fossil revert, etc.) Fossil remembers the prior state and is able to return the check-out directory to that state with a fossil undo command. While you cannot undo a commit in Fossil — on purpose! — as long as the change remains confined to the local check-out directory only, Fossil makes undo easier than in Git.

Fossil is small, complete, and self-contained. If you clone Git’s self-hosting repository, you get just Git’s source code. If you clone Fossil’s self-hosting repository, you get the entire Fossil website — source code, documentation, ticket history, and so forth.² That means you get a copy of this very article and all of its historical versions, plus the same for all of the other public content on this site.

Git is actually a collection of many small tools, each doing one small 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 depends only on common platform libraries in its default configuration. To install one of our precompiled binaries, unpack the executable from the archive and put it somewhere in your PATH. To uninstall it, delete the executable.

This policy is particularly useful when running Fossil inside a restrictive container, anything from classic chroot jails to modern OS-level virtualization mechanisms such as Docker. Our stock container image is under 8 MB when uncompressed and running. It contains nothing but a single statically-linked binary.

If you build a dynamically linked binary instead, Fossil’s on-disk size drops to around 6 MB, and it’s dependent only on widespread platform libraries with stable ABIs such as glibc, zlib, and openssl.

Full static linking is easier on Windows, so our precompiled Windows binaries are just a ZIP archive containing only “fossil.exe”. There is no “setup.exe” to run.

Fossil is easy to build from sources. Just run “./configure && make” on POSIX systems and “nmake /f Makefile.msc” on Windows.

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 Fossil project itself is hosted on a small and inexpensive VPS. A bare-bones $5/month VPS or a spare Raspberry Pi is sufficient to run a full-up project site, complete with tickets, wiki, chat, and forum, in addition to being a code repository.

The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems manage a directed acyclic graph (DAG) of Merkle tree structured check-in objects. Check-ins are identified by a cryptographic hash of the check-in contents, and each check-in refers to its parent via the parent’s hash.

The difference is that Git stores its objects as individual files in the .git folder or compressed into bespoke key/value pack-files, whereas Fossil stores its objects in a SQLite database file which provides ACID transactions and a high-level query language. This difference is more than an implementation detail. It has important practical consequences.

Leaf check-ins in Git that lack a “ref” become “detached,” making them difficult to locate and subject to garbage collection. This detached head state problem has caused grief for many Git users. With Fossil, detached heads are simply impossible because we can always find our way back into the Merkle tree using one or more of the relations in the SQL database.

The bottom line is that even though Fossil and Git are built around the same low-level data structure, the use of SQL to query this data makes the data more accessible in Fossil, resulting in more detailed information being available to the user. This improves situational awareness and makes working on the project easier.

Over half of the C code in Fossil is actually an embedded copy of the current version of SQLite. Much of what is Fossil-specific after you set SQLite itself aside is SQL code calling into SQLite. The number of lines of SQL code in Fossil isn’t large by percentage, but since SQL is such an expressive, declarative language, it has an outsized contribution to Fossil’s user-visible functionality.

Fossil isn’t entirely C and SQL code. Its web UI uses JavaScript where necessary. The server-side UI scripting uses a custom minimal Tcl dialect called TH1, which is embedded into Fossil itself. Fossil’s build system and test suite are largely based on Tcl.⁵ All of this is quite portable.

While Fossil does lean toward POSIX norms when given a choice — LF-only line endings are treated as first-class citizens over CR+LF, for example — the Windows build of Fossil is truly native.

The third-party extensions to Git tend to follow this same pattern. GitLab isn’t portable to Windows at all, for example. For that matter, GitLab isn’t even officially supported on macOS, the BSDs, or uncommon Linuxes! We have many users who regularly build and run Fossil on all of these systems.

In the following sections, we will explain how four key differences between the Linux and SQLite software development projects dictated the design of each DVCS’s low-friction usage path.

When deciding between these two DVCSes, you should ask yourself, “Is my project more like Linux or more like SQLite?”

Eric S. Raymond’s seminal essay-turned-book “The Cathedral and the Bazaar” details the two major development organization styles found in FOSS projects. As it happens, Linux and SQLite fall on opposite sides of this dichotomy. Differing development organization styles dictate a different design and low-friction usage path in the tools created to support each project.

Where Git encourages siloed development, Fossil fights against it. Fossil places a lot of emphasis on synchronizing everyone’s work and on reporting on the state of the project and the work of its developers, so that everyone — especially the project leader — can maintain a better mental picture of what is happening, leading to better situational awareness.

By contrast, “…forking is at the core of social coding at GitHub”. As of January 2022, Github hosts 47 million distinct software projects, most of which were created by forking a previously-existing project. Since this is roughly twice the number of developers in the world, it beggars belief that most of these forks are still under active development. The vast bulk of these must be abandoned one-off efforts. This is part of the nature of bazaar style development.

95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model.

When choosing your DVCS, we think you should ask yourself whether the scale of your software configuration management problems is closer to those Linus Torvalds designed Git to cope with or whether your work’s scale is closer to that of SQLite, for which D. Richard Hipp designed Fossil. An automotive air impact wrench running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is not the best way to hang a picture on the living room wall.

Fossil works well for projects several times the size of SQLite, such as Tcl, with a repository over twice the size and with many more core committers.

Both Fossil and Git store history as a directed acyclic graph (DAG) of changes, but Git tends to focus more on individual branches of the DAG, whereas Fossil puts more emphasis on the entire DAG.

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 single work/repo tree, even when that’s a shortsighted way of working.

Fossil doesn’t work that way. A Fossil repository is an SQLite database file which is normally stored outside the working checkout directory. You can open a Fossil repository any number of times into any number of working directories. A common usage pattern is to have one working directory per active working branch, so that switching branches is done with a cd command rather than by checking out the branches successively in a single working directory.