Small. Fast. Reliable.
Choose any three.
Why SQLite Does Not Use Git

1. Introduction

SQLite does not use the Git version control system. SQLite uses Fossil instead, which is a version control system that was specifically designed and written to support SQLite.

People sometimes ask why SQLite does not use the Git version control system like everybody else. This article attempts to answer that question. Also, in section 3, this article provides hints to Git users about how they can easily access the SQLite source code.

This article is not a comparison between Fossil and Git. See for a comparison of the two systems.

1.1. Edits

This article has been revised multiple times in an attempt to improve clarity, address concerns and misgivings, and to fix errors identified on Hacker News, Reddit and Lobsters. The complete edit history can be seen at

2. A Few Reasons Why SQLite Does Not Use Git

One could summarize the reason why SQLite does not use Git in a single sentence: The lead SQLite developer finds Git to be unpalatable. If you like Git and want to use it, that's great. I do not like Git and would rather use something that I think is better.

The following are a few of the reasons why I do not like Git:

2.1. Git makes it difficult to find successors (descendents) of a check-in

Git allows you to go backwards in time easily. Given the latest check-in on a branch, Git lets you see all the ancestors of that check-in. But Git makes it difficult to move in the other direction. Given some historical check-in, it is quite challenging in Git to find out what came next. It can be done, but it is sufficiently difficult that people rarely do it. Common interfaces for Git, such as GitHub, do not support the ability.

It is not impossible to find the descendents of a check-in in Git. It is merely difficult. For example, there is a stackoverflow page showing the command sequence for finding the descendents of a check-in in unix:

git rev-list --all --parents | grep ".\{40\}.*.*" | awk '{print $1}'

This command sequence is a lot to memorize and type. (One would want to create a bash alias or short shell script if it were used frequently.) Furthermore, it is not quite the same thing. The command above gives one a list of descendents without showing the branching structure, which is important for understanding what happened. In contrast, Fossil offers displays such as, which is a tremendous help in analyzing the aftermath of historical changes.

And it is not really about just finding the descendents of a check-in from time to time. The fact that descendents are readily available in Fossil means that the information pervades the web pages provided by Fossil. One example: Every Fossil check-in information page (example) shows a small "Context" graph of the immediate predecessor and successors to that check-in. This helps the user maintain better situational awareness, and it provides useful capabilities, such as the ability click forward to the next check-in in sequence. Another example: Fossil easily shows the context around a specific check-in (example) which again helps to promote situational awareness and a deeper understanding of what is happening in the code.

All of the above is possible with Git, given the right extensions and tools and using the right commands. But it is not easy to do, and so it rarely gets done. Consequently, developers have less awareness of what is happening in the code.

2.2. The mental model for Git is needlessly complex

The complexity of Git distracts attention from the software under development. A user of Git needs to keep all of the following in mind:

  1. The working directory
  2. The "index" or staging area
  3. The local head
  4. The local copy of the remote head
  5. The actual remote head

Git contains commands (or options on commands) for moving and comparing content between all of these locations.

In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Every developer has a finite number of brain-cycles. Fossil requires fewer brain-cycles to operate, thus freeing up intellectual resources to focus on the software under development.

One user of both Git and Fossil writes in HN:

Fossil gives me peace of mind that I have everything ... synced to the server with a single command.... I never get this peace of mind with git.

2.3. Git does not track historical branch names

Git keeps the complete DAG of the check-in sequence. But branch tags are local information that is not synced and not retained once a branch closes. This makes review of historical branches tedious.

As an example, consider display of a single historical branch of SQLite as rendered by GitHub and by Fossil:

The Fossil view clearly shows that the branch was eventually merged back into trunk. It shows where the branch started, and it shows two occasions where changes on trunk were merged into the branch. GitHub shows none of this. In fact, the GitHub display is mostly useless in trying to figure out what happened.

Many readers have recommended various third-party GUIs for Git that might do a better job of showing historical development activity. Maybe some of them do work better than native Git and/or GitHub, though they will all be hampered by the fact that Git does not preserve historical branch names across syncs. And even if those other tools are better, the fact that it is necessary to go to a third-party tool to get the information desired does not speak well of the core system.

2.4. Git requires more administrative support

Git is complex software. One needs an installer of some kind to put Git on a developer workstation, or to upgrade to a newer version of Git. Setting up a Git server is non-trivial. One could use GitHub, but that introduces another third-party dependency and a centralized service, which mitigate the key advantage of Git which is that it is "distributed". There are various free alternatives to GitHub, such as GitLab, but those too have a lot of dependencies and require a lot of server setup.

In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software required.

Less administration means that programmers spend more time working on the software (SQLite in this case) and less time fussing with the version control system.

2.5. Git provides a poor user experience

The following cartoon is an exaggeration, yet hits close to home:

Let's be real. Few people seriously dispute that Git provides a suboptimal user experience. A lot of the underlying implementation shows through into the user interface. The interface is so bad that there is even a parody site that generates fake git man pages.

Designing software is hard. It takes a lot of focus. A good version control system should provide the developer with assistance, not frustration. Git has gotten better in this regard over the past decade, but it still has a long way to go. And so, the developers of SQLite plan to continue using a different version control system for now.

3. A Git-User's Guide To Accessing SQLite Source Code

If you are a devoted Git user, you can still easily access SQLite. This section gives some hints on how to do so.

3.1. GitHub Mirrors

There is a mirror of the SQLite source tree on GitHub at This mirror is maintained by user "mackyle" who is unaffiliated with, and unknown to, the official SQLite development team. We do not know mackyle, but we observe that he does a terrific job of keeping his mirror current, and so if you want to access the SQLite source code on GitHub, his mirror is the recommended source.

3.2. Web Access

The SQLite Fossil Repository contains links for downloading a Tarball, ZIP Archive, or SQLite Archive for any historical version of SQLite. The URLs for these downloads are simple and can be incorporated easily into automated tools. The format is:

Simply replace VERSION with some description of the version to be downloaded. The VERSION can be a prefix of the cryptographic hash name of a specific check-in, or the name of a branch (in which case the most recent version of the branch is fetched) or a tag for a specific check-in like "version-3.23.1":

To get the latest release, use "release" for VERSION, like this:

To get the latest trunk check-in, us "trunk" for VERSION:

And so forth. For ZIP archives and SQLite Archives, simply change the "/tarball/" element into either "/zip/" or "/sqlar/", and maybe also change the name of the download file to have a ".zip" or ".sqlar" suffix.

3.3. Fossil Access

Fossil is easy to install and use. Here are the steps for unix. (Windows is similar.)

  1. Download the self-contained Fossil executable from and put the executable somewhere on your $PATH.
  2. mkdir ~/fossils
  3. fossil clone ~/fossils/sqlite.fossil
  4. mkdir ~/sqlite; cd ~/sqlite
  5. fossil open ~/fossils/sqlite.fossil

At this point you are ready to type "./configure; make" (or on Windows with MSVC, "nmake /f Makefile.msc").

To change your checkout to a different version of Fossil use the "update" command:

fossil update VERSION

Use "trunk" for VERSION to get the latest trunk version of SQLite. Or use a prefix of a cryptographic hash name, or the name of some branch or tag. See for more suggestions on what names can be used for VERSION.

Use the "fossil ui" command from within the ~/sqlite checkout to bring up a local copy of the website.

Additional documentation on Fossil can be found at

Do not be afraid to explore and experiment. Without a log-in you won't be able to push back any changes you make, so you cannot damage the project.

4. See Also

Other pages that talk about Fossil and Git include: