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:
GIT FOSSIL File versioning only Versioning, Tickets, Wiki, and Blog/News Sharding Replicating Huge community Road less traveled Complex Intuitive Separate web tools Integrated Web interface Lots of little tools Single executable Pile-of-files repository Single file repository Uses "rebase" Immutable GPL BSD
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 News/Blog features. 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 branchs of the project private. This is analogous to sharding an a distributed database.
Fossil allows private branches, but its default mode is to share everything. And so in a Fossil project, all respositories 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 Community
Git has a huge user community. If following the herd and being like everybody else is important to you, then you should choose Git.
Fossil is clearly the "road less traveled":
Two roads diverged in a wood, and I —
I took the one less traveled by,
And that has made all the difference.
- Robert Frost, The Road Not Taken, 1916
Among the advantages of Git's huge user community are that new team members may already be familiar with Git's operation and hence can bypass the VCS learning curve. Also, if you need an add-on tool or script of some kind, a Google search will likely turn up a suitable tool that you can just download and use. A huge community also means that somebody else has likely already encountered and fixed the bugs so that Git will work for you and your project as advertised.
Among the advantages of the "road less traveled" is that your particular project will be bigger percentage of the total user base, and is thus more likely to receive personal attention from the Fossil maintainers if you do encounter problems.
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.
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 highly resistant to damage from a power-loss or system crash - incomplete transactions are simply rolled back after the system reboots.
3.8 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. From another point of view, rebase can be used to "rewrite history" - to do what Winston Smith did for a living in Orwell's novel 1984.
Fossil deliberately avoids rewriting history. Fossil strives to follow the accounting philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. The lack of a "rebase" function is considered a feature of Fossil, not a bug.
3.9 License
Both Git and Fossil are open-source. Git is under GPL whereas Fossil is under the two-clause BSD license. The difference should not be of a concern to most users. However, some corporate lawyers have objections to using GPL products and are more comfortable with a BSD-style license.