Fossil Versus Git

1.0 Don't Stress!

If you start out using one DVCS and later decide you like the other better, it is easy to change.

But it also helps to be informed about the differences between Git and Fossil. 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, so the information here might be biased in favor of Fossil. Ask around with people who have used both Fossil and Git for other opinions.

2.0 Executive Summary:

File versioning only Versioning, Tickets, Wiki, and Technotes
Developer branchesFeature branches
Separate web toolsIntegrated Web interface
Lots of little toolsSingle executable
Pile-of-files repository Single-file relational database
One check-out per repository Many check-outs per repository
Uses "rebase"Immutable

3.0 Discussion

3.1 Feature Set

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

3.2 Sharding versus Replicating

Git makes it easy for each repository in a project to hold a subset of the branches for that project. In fact, it is entirely possible and not uncommon for no repository in the project to hold all the different code versions for a project. Instead the information is distributed. Individual developers have one or more private branches. A hierarchy of integrators merge changes from individual developers into collaborative branches, until all the changes are merged together at the top-level master branch. And all of this can be accomplished without having to have all the code in any one repository. Developers or groups of developers can share only those branches that they want to share and keep other branches of the project private. This is analogous to sharding a distributed database.

Fossil allows private branches, but its default mode is to share everything. And so in a Fossil project, all repositories tend to contain all of the content at all times. This is analogous to replication in a distributed database.

The Git model works best for large projects, like the Linux kernel for which Git was designed. Linus Torvalds does not need or want to see a thousand different branches, one for each contributor. Git allows intermediary "gate-keepers" to merge changes from multiple lower-level developers into a single branch and only present Linus with a handful of branches at a time. Git encourages a programming model where each developer works in his or her own branch and then merges changes up the hierarchy until they reach the master branch.

Fossil is designed for smaller and non-hierarchical teams where all developers are operating directly on the master branch, or at most a small number of well-defined branches. The autosync mode of Fossil makes it easy for multiple developers to work on a single branch and maintain linear development on that branch and avoid needless forking and merging.

3.3 Branches

Git (and especially GitHub) encourages a workflow where each developer has his or her own branch or branches. Developers then send "pull requests" to have their changes be merged into "official" branches by integrators. For example, the Linux kernel team has a hierarchy of integrators with Linus Torvalds at the root. Individual developers each have their own private branches of the source tree into which they make their own changes. They then encourage first-tier integrators to pull those changes. The first-tier integrators merge together changes from multiple contributors then try to get second-tier integrators to pull their branches. The changes merge up the hierarchy until (hopefully) they are pulled into "Linus's branch", at which time they become part of the "official" Linux.

In Git, each branch is "owned" by the person who creates it and works on it. The owner might pull changes from others, but the owner is always in control of the branch. Branches are developer-centric.

Fossil, on the other hand, encourages a workflow where branches are associated with features or releases, not individual developers. All developers share all branches in common, and two or more developers can and often do intersperse commits onto the same branch. Branches do not belong to individuals. All branches are read/write accessible to all developers at all times. There is no need for integrators to merge together changes from various independent developers. Instead, all of the developers work together cooperatively and the changes stay integrated naturally.

So to a first approximation, branches in Git are developer-centric whereas branches in Fossil are feature-centric.

The Git approach scales much better for large projects like the Linux kernel with thousands of contributors who in many cases don't even know each other's names. The integrators serve a gatekeeper role to help keep undesirable code out of the official Linux source tree. On the other hand, not many projects are as big or as loosely organized as the Linux kernel. Most projects have a small team of developers who all know each other well and trust each other, and who enjoy working together collaboratively without the overhead and hierarchy of integrators.

One consequence of the "everybody-sees-everything" focus of Fossil is that branch names are global and are part of the distributed and synchronized content of a Fossil repository, rather than being private and user-specific as they are in Git.

3.4 Complexity

Git is a complex system. It can be tricky to use and requires a fair amount of knowledge and experience to master. Fossil strives to be a much simpler system that can be learned and mastered much more quickly. Fossil strives to have fewer "gotchas" and quirks that can trip up a developer.

The ideal VCS should just get out of the way of the developer and allow the developer to focus 100% of their thinking on the project under development. One should not have to stop and think about how to operate the VCS. Of course, no VCS is ideal. Every VCS requires the developer to think about version control to some extent. But one wants to minimize the thinking about version control.

Git requires the developer to maintain a more complex mental model than most other DVCSes. Git takes longer to learn. And you have to spend more time thinking about what you are doing with Git.

Fossil strives for simplicity. Fossil wants to be easy to learn and to require little thinking about how to operating it. Reports from the field indicate that Fossil is mostly successful at this effort.

Fossil will never get you into anything like the "disconnected head state" which has frustrated so many Git users.

3.5 Web Interface

Git has a web interface, but it requires a fair amount of setup and an external web server. Fossil comes with a fully functional built-in web-server and a really simple mechanism (the "fossil ui" command) to automatically start the web server and bring up a web browser to navigate it. The web interface for Fossil is not only easier to set up, it is also more powerful and easier to use. The web interface to Fossil is a practical replacement to the 3rd-party "GUI Tools" that users often employ to operate Git.

3.6 Implementation Strategy

Git consists of a collection of many little programs. Git needs to be "installed" using some kind of installer or package tool. Git can be tricky to install and get working, especially for users without administrative privileges.

Fossil is a single self-contained executable. To "install" Fossil one has merely to download a precompiled binary and place that binary somewhere on $PATH. To uninstall Fossil, simply delete the binary. To upgrade Fossil, replace the old binary with a new one.

Fossil is designed to be trivial to install, uninstall, and upgrade so that developers can spend more time working on their own projects and much less time configuring their version control system.

3.7 Repository Storage

A Git repository is a "pile-of-files" in the ".git" directory at the root of the working checkout. There is a one-to-one correspondence between repositories and working checkouts. A power-loss or system crash in the middle of Git operation can damage or corrupt the Git repository.

A Fossil repository consists of a single disk file. A single Fossil repository can serve multiple simultaneous working checkouts. A Fossil repository is an SQLite database, so it is highly resistant to damage from a power-loss or system crash - incomplete transactions are simply rolled back after the system reboots.

3.8 Check-outs Per Repository

In Git, a check-out and a repository are joined in a fundamental way so that only a single version of the project history, or a single branch, can be open at once. If you have a project with multiple branches and you want to have two or more branches open at the same time (perhaps to do performance comparisons, or maybe to run simultaneous builds using different compile-time options) then in Git you actually have to create a new clone of the repository for each open checkout.

In Fossil, the repository and the check-out are distinct entities and so a single repository can support multiple simultaneous checkouts. This feature is extensively used by the Fossil developers themselves. Perhaps we are biased, but we not understand how anyone can work efficiently with just one check-out per repository.

3.9 Audit Trail

Git features the "rebase" command which can be used to change the sequence of check-ins in the repository. Rebase can be used to "clean up" a complex sequence of check-ins to make their intent easier for others to understand. This is important if you view the history of a project as part of the documentation for the project.

Fossil takes an opposing view. Fossil views history as sacrosanct and stubbornly refuses to change it. Fossil allows mistakes to be corrected (for example, check-in comments can be revised, and check-ins can be moved onto new branches even after the check-in has occurred) but the correction is an addition to the repository and the original actions are preserved and displayed alongside the corrections, thus preserving an historically accurate audit trail. This is analogous to an accounting practice of marking through an incorrect entry in a ledger and writing a correction beside it.

To put it another way, Git remembers what you should have done whereas Fossil remembers what you actually did.

The lack of a "rebase" command and the inability to rewrite history is considered a feature of Fossil, not an omission or bug.

3.10 License

Both Git and Fossil are open-source. Git is under GPL whereas Fossil is under the two-clause BSD license. The different licenses parallel, to some extent, the different philosophies of Git and Fossil. There are exceptions on both sides, but to a first approximation, Git works better for GPL projects and Fossil works better for BSD projects.

The GPL is designed to provide a very contributor-friendly environment. No legal paperwork is needed to contribute to a GPL project because the GPL is cleverly designed so that the act of contributing to the project (or even reading the code for the project) constitutes an acceptance of the licensing terms. GPL encourages a bazaar-style development model, with lots of anonymous programmers contributing drive-by patches. The theory is that with many eyeballs, all bugs are shallow. Surprisingly, this has actually been demonstrated to work in many well-known projects.

The BSD-style licenses are more user-friendly. BSD-style licenses place fewer restrictions on the users of the software at the expense of making it more difficult to contribute changes or enhancements. To protect against IP claims, every contributor to a BSD-style project must sign legal documents in which they agree to release their contributions under the same license. (Some BSD-licensed projects omit this formality, but do so at their peril.) A BSD-style license encourages a more cathedral-style approach to development. There is a small team of developers. Drive-by patches and anonymous contributors are discouraged and/or prohibited. Contributors are expected to be experts and be available to support their changes for the long-term.