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.