Introduction

SQLite does not use the [https://git-scm.org|Git] version control system. SQLite uses [https://fossil-scm.org/|Fossil] instead. Fossil and Git are both block-chain version-control systems. They are both "distributed". They both store content as a sequence of immutable check-ins identified by a cryptographic hash. Git is wildly popular, to the point that many younger developers are familiar with nothing else. And yet, the developers of SQLite prefer Fossil. This article tries to explain why.

A Few Reasons Why SQLite Does Not Use Git

  1. With Git, it is very difficult to find the successors (decendents) of a check-in.

    Git allows you to go backwards in time. Given the latest check-in on a branch, Git lets you see all the ancestors of that check-in. But Git makes it very 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 and slow that nobody ever does it. There is no button in GitHub that shows the descendents of a check-in.

    This is a deal-breaker, a show-stopper. The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite.

  2. The mental model for Git is needlessly complex and consequently distracts attention from 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.

  3. Git does not track branch history. 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:

    • GitHub: [https://github.com/mackyle/sqlite/commits/prefer-coroutine-sort-subquery]
    • Fossil: [https://sqlite.org/src/timeline?r=prefer-coroutine-sort-subquery]

    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.

  4. Git lacks native wiki and bug tracking. If you want these essential features, you have to install additional software such as GitLab, or else use a third-party service such as GitHub. And even then, the wiki and bug reports are centralized, not distributed.

  5. Git requires more administrative support. Setting up a website for a project to use Git requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil.

  6. Nobody really understands Git.
    (credit: [https://xkcd.com/1597/])

See Also

Other pages that talk about Fossil and Git include:

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

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

GitHub Mirrors

There is a mirror of the SQLite source tree on GitHub at [https://github.com/mackyle/sqlite]. 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.

Web Access

The [https://sqlite.org/src/timeline|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:

https://sqlite.org/src/tarball/VERSION/sqlite.tar.gz

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.0".

Fossil Access

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

  1. Download the self-contained Fossil executable from [https://fossil-scm.org/fossil/uv/download.html] and put the executable somewhere on your $PATH.
  2. mkdir ~/fossils
  3. fossil clone https://fossil-scm.org/fossil ~/fossils/sqlite.fossil
  4. mkdir ~/sqlite; cd ~/sqlite
  5. fossil open ~/sqlite.fossil .

Subsequently, to update your check-out, simply type:

fossil up 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.

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