SQLite Doesn't Use Git

Instead, it uses Fossil as a version control system. Some thoughts.

Fossil is also developed by the same primary author as SQLite (D. Richard Hipp). Like SQLite, they share some similar design philosophies (at a very high level):

• All-in-one product – Fossil takes the main ideas of VCS and extends them by including bug tracking, wiki, alerting, chat, and a web interface. Whether or not that makes it more of an alternative to git or GitHub is another question. What comes after git? (APIs – ok, everything else might be feature creep).
• SQLite as a database – Fossil uses SQLite as a database instead of Git's object model. This makes it easy to back up and store repositories.
• Fossil does not support rebase. Here's an article from the author titled, Rebase Considered Harmful. While Fossil has the ability to squash merges, the primary workflow supported is merging. I appreciate the opinionated workflow (vs. git's squash, merge, or rebase), but I still believe that a squash+merge (or sometimes, rebase) workflow pairs better with pull requests.
• 85% of the commits (to SQLite) are from two users. The project has around 37 contributors (activity report). Fossil is a bit more diverse, with 128 different contributors (top 2 contributors at 49%). On the surface, this is contrary to most open source projects, although I still believe the bulk of the work on many OSS projects comes from a few key contributors. The project is also notorious for not accepting outside patches or contributions.

Fossil not only serves as a good testing ground for SQLite but an alternative approach to version control systems – a category that hasn't evolved much since git was developed.