1.0 Don't Stress!

If you start out using one DVCS and later decide you like the other better, you can easily move your content.¹

Fossil and Git are very similar in many respects, but they also have important differences. See the table below for a high-level summary and the text that follows for more details.

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. Ask around for second opinions from people who have used both Fossil and Git.

¹Git does not include a wiki, a ticket tracker, a forum, or a tech-note feature, so those elements will not transfer when exporting from Fossil to Git. GitHub adds some of these to stock Git, but because they're not part of Git proper, exporting a Fossil repository to GitHub will still not include them; Fossil tickets do not become GitHub issues, for example.

2.0 Differences Between Fossil And Git

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

GIT	FOSSIL
File versioning only	Versioning, Tickets, Wiki, Technotes, Forum
Ad-hoc pile-of-files key/value database	Relational SQL database
Bazaar-style development	Cathedral-style development
Designed for Linux kernel development	Designed for SQLite development
Focus on individual branches	Focus on the entire tree of changes
Lots of little tools	Stand-alone executable
One check-out per repository	Many check-outs per repository
Remembers what you should have done	Remembers what you actually did
GPL	BSD

2.1 Feature Set

Git provides file versioning services only, whereas Fossil adds integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, and a forum. These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design. One way to describe Fossil is that it is "GitHub-in-a-box."

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.

For developers who choose to self-host projects (rather than using a 3rd-party service such as GitHub) Fossil is much easier to set up, since the stand-alone Fossil executable together with a 2-line CGI script suffice to instantiate a full-featured developer website. To accomplish the same using Git requires locating, installing, configuring, integrating, and managing a wide assortment of separate tools. Standing up a developer website using Fossil can be done in minutes, whereas doing the same using Git requires hours or days.

2.2 Database

The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems store check-ins as immutable objects referencing their immediate ancestors and named by a cryptographic hash of the check-in content.

The difference is that Git stores its objects as individual files in the ".git" folder or compressed into bespoke "pack-files," whereas Fossil stores its objects in a relational (SQLite) database file. To put it another way, Git uses an ad-hoc pile-of-files key/value database whereas Fossil uses a proven, general-purpose SQL database. This difference is more than an implementation detail. It has important consequences.

With Git, one can easily locate the ancestors of a particular check-in by following the pointers embedded in the check-in object, but it is difficult to go the other direction and locate the descendants of a check-in. It is so difficult, in fact, that neither native Git nor GitHub provide this capability. With Git, if you are looking at some historical check-in then you cannot ask "What came next?" or "What are the children of this check-in?"

Fossil, on the other hand, parses essential information about check-ins (parents, children, committers, comments, files changed, etc.) into a relational database that can be easily queried using concise SQL statements to find both ancestors and descendents of a check-in.

Leaf check-ins in Git that lack a "ref" become "detached," making them difficult to locate and subject to garbage collection. This "detached head" problem has caused untold grief for countless Git users. With Fossil, all check-ins are easily located using a variety of attributes (parents, children, committer, date, full-text search of the check-in comment) and so detached heads are simply not possible.

The ease with which check-ins can be located and queried in Fossil has resulted in a huge variety of reports and status screens (examples) that show project state in ways that help developers maintain enhanced awareness and comprehension and avoid errors.

2.3 Cathedral vs. Bazaar

Fossil and Git promote different development styles. Git promotes a "bazaar" development style in which numerous anonymous developers make small and sometimes haphazard contributions. Fossil promotes a "cathedral" development model in which the project is closely supervised by an highly engaged architect and implemented by a clique of developers.

Nota Bene: This is not to say that Git cannot be used for cathedral-style development or that Fossil cannot be used for bazaar-style development. They can be. But those modes are not their design intent nor their low-friction path.

Git encourages a style in which individual developers work in relative isolation, maintaining their own branches and occasionally rebasing and pushing selected changes up to the main repository. Developers using Git often have their own private branches that nobody else ever sees. Work becomes siloed. This is exactly what one wants when doing bazaar-style development.

Fossil, in contrast, strives to keep all changes from all contributors mirrored in the main repository (in separate branches) at all times. Work in progress from one developer is readily visible to all other developers and to the project leader, well before the code is ready to integrate. Fossil places a lot of emphasis on reporting the state of the project, and the changes underway by all developers, so that all developers and especially the project leader can maintain a better mental picture of what is happening, and better situational awareness.

2.4 Linux vs. SQLite

Git was specifically designed to support the development of the Linux kernel. Fossil was specifically designed to support the development of SQLite.

SQLite is much more widely deployed than the Linux kernel, but for Linux-based systems, the kernel is the more fundamental component. Although both projects must rank high on any objective list of "most important FOSS projects," the two projects are almost entirely unlike one another, and this shows up in the design choices of the tools created to support them.

The Linux kernel uses a bazaar-style development model. There are thousands and thousands of contributors, most of whom do not know each others names. These thousands are responsible for producing roughly 89⨉ more code than is in SQLite. (10.7 MLOC vs 0.12 MLOC according to SLOCCount.) Git is designed for this scenario.

SQLite uses cathedral-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 is designed for this development model.

We think you should ask yourself whether you have Linus Torvalds scale software configuration management problems or D. Richard Hipp scale problems when choosing your DVCS. You don't use a pneumatic ratchet wrench to hang a picture on the living room wall.

2.5 Individual Branches vs. The Entire Change History

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.

For example, the default "sync" behavior in Git is to only sync a single branch, whereas with Fossil the only sync option it to sync the entire DAG. Git commands, GitHub, and GitLab tend to show only a single branch at a time, whereas Fossil usually shows all parallel branches at once. Git has commands like "rebase" that help keep all relevant changes on a single branch, whereas Fossil encourages a style of many concurrent branches constantly springing into existance, undergoing active development in parallel for a few days or weeks, then merging back into the main line and disappearing.

This difference in emphasis arises from the different purposes of 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.

2.6 Lots of little tools vs. Self-contained system

Git consists 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 and requires an "installer" script or program to get it running.

Fossil is a single self-contained stand-alone executable with hardly any dependencies. Fossil can be (and often is) run inside a minimally configured chroot jail. To install Fossil, one merely puts the executable somewhere in the $PATH.

The designer of Git says that the Unix philosophy is to have lots of small tools that collaborate to get the job done. The designer of Fossil says that the Unix philosophy is "It just works." Both individuals have written their DVCSes to reflect their own view of the "Unix philosophy."

2.7 One vs. Many Check-outs per Repository

A "repository" in Git is a pile-of-files in the ".git" subdirectory of a single check-out. The check-out and the repository are located together in the filesystem.

With Fossil, a "repository" is a single SQLite database file that can be stored anywhere. There can be multiple active check-outs from the same repository, perhaps open on different branches or on different snapshots of the same branch. Long-running tests or builds can be running in one check-out while changes are being committed in another.

Git version 2.5 adds a feature to emulate Fossil's decoupling of the repository from the check-out tree, which it calls "git-worktree." This command sets up a series of links in the filesystem to allow a single repository to host multiple check-outs. However, the interface is sufficiently difficult to use that most people find it easier to create a separate clone for each check-out. There are also practical consequences of the way it's implemented that make worktrees not quite equivalent to the main Git repo + checkout tree.

With Fossil, the complete decoupling of repository and check-out tree means every working check-out tree is treated equally. It's common in Fossil to have a check-out tree for each major working branch so that you can switch branches with a "cd" command rather than replace the current working file set with a different file set by updating in place, as Git prefers.

2.8 What you should have done vs. What you actually did

Git puts a lot of emphasis on maintaining a "clean" check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. And branches are often rebased before being pushed, to make it appear as if development had been linear. Git strives to record what the development of a project should have looked like had there been no mistakes.

Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project "messy." But another point of view is that this makes the history "accurate." In actual practice, the superior reporting tools available in Fossil mean that the added "mess" is not a factor.

One commentator has mused that Git records history according to the victors, whereas Fossil records history as it actually happened.

2.9 GPL vs. BSD

Git is covered by the GPL license whereas Fossil is covered by a two-clause BSD style license.

Consider the difference between GPL and BSD licenses: GPL is designed to make writing easier at the expense of making reading harder. BSD is designed to make reading easier at the expense of making writing harder.

To a first approximation, the GPL license grants the right to read source code to anyone who promises to give back enhancements. In other words, the act of reading GPL source code (a prerequiste for making changes) implies acceptance of the license which requires updates to be contributed back under the same license. (The details are more complex, but the foregoing captures the essence of the idea.) A big advantage of the GPL is that anybody can contribute to the code without having to sign additional legal documentation because they have implied their acceptance of the GPL license by the very act of reading the source code. This means that a GPL project can legally accept anonymous and drive-by patches.

The BSD licenses, on the other hand, make reading much easier than the GPL, because the reader need not surrender proprietary interest in their own enhancements. On the flip side, BSD and similarly licensed projects must obtain legal affidavits from authors before new content can be added into the project. Anonymous and drive-by patches cannot be accepted. This makes signing up new contributors for BSD licensed projects harder.

The licenses on the implementations of Git and Fossil only apply to the implementations themselves, not to the projects which the systems store. Nevertheless, one can see a more GPL-oriented world-view in Git and a more BSD-oriented world-view in Fossil. Git encourages anonymous contributions and siloed development, which are hallmarks of the GPL/bazaar approach to software, whereas Fossil encourages a more tightly collaborative, cliquish, cathedral-style approach more typical of BSD-licensed projects.

3.0 Missing Features

Most of the capabilities found in Git are also available in Fossil and the other way around. For example, both systems have local check-outs, remote repositories, push/pull/sync, bisect capabilities, and a "stash." Both systems store project history as a directed acyclic graph (DAG) of immutable check-in objects.

But there are a few capabilities in one system that are missing from the other.

3.1 Features found in Fossil but missing from Git

• The ability to show descendents of a check-in.

Both Git and Fossil can easily find the ancestors of a check-in. But only Fossil shows the descendents. (It is possible to find the descendents of a check-in in Git using the log, but that is sufficiently difficult that nobody ever actually does it.)

• Wiki, Embedded documentation, Trouble-tickets, Tech-Notes, and Forum

Git only provides versioning of source code. Fossil strives to provide other related project management services as well.

• Named branches

Branches in Fossil have persistent names that are propagated to collaborators via push and pull. All developers see the same name on the same branch. Git, in contrast, uses only local branch names, so developers working on the same project can (and frequently do) use a different name for the same branch.

• The fossil all command

Fossil keeps track of all repositories and check-outs and allows operations over all of them with a single command. For example, in Fossil is possible to request a pull of all repositories on a laptop from their respective servers, prior to taking the laptop off network. Or it is possible to do "fossil all changes" to see if there are any uncommitted changes that were overlooked prior to the end of the workday.

• The fossil ui command

Fossil supports an integrated web interface. Some of the same features are available using third-party add-ons for Git, but they do not provide nearly as many features and they are not nearly as convenient to use.

3.2 Features found in Git but missing from Fossil

• Rebase

Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it is not something that can be done with a single command.

• Push or pull a single branch

The fossil push, fossil pull, and fossil sync commands do not provide the capability to push or pull individual branches. Pushing and pulling in Fossil is all or nothing. This is in keeping with Fossil's emphasis on maintaining a complete record and on sharing everything between all developers.