Fossil versus Git

Summary

1.0 Don't Stress! The feature sets of Fossil and Git overlap in many ways. Both are distributed version control systems which store a tree of check-in objects to a local repository clone. In both systems, the local clone starts out as a full copy of the remote parent. New content gets added to the local clone and then later optionally pushed up to the remote, and changes to the remote can be pulled down to the local clone at will. Both systems offer diffing, patching, branching, merging, cherry-picking, bisecting, private branches, a stash, etc. 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. 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. GITFOSSILmore File versioning only VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC 2.1 ↓ A federation of many small programs One self-contained, stand-alone executable 2.2 ↓ Custom key/value data store The most used SQL database in the world 2.3 ↓ Runs natively on POSIX systems Runs natively on both POSIX and Windows 2.4 ↓ Bazaar-style development Cathedral-style development 2.5.1 ↓ Designed for Linux kernel development Designed for SQLite development 2.5.2 ↓ Focus on individual b...