Why SQLite doesn't adopt Git as its version control system



Git is a distributed version control system developed to manage Linux kernel source code, and GitHub, which hosts Git repositories, has over 100 million users. On the other hand, in the development of the lightweight database SQLite, a version control system called Fossil is used instead of Git, and the SQLite development team explains on the official website why they do not use Git.

Why SQLite Does Not Use Git

https://sqlite.org/whynotgit.html

You can find out what kind of functions Fossil has as a version control system by reading the article below.

``Fossil'' review that packs Git and GitHub functions into one binary - GIGAZINE



1: Git doesn't provide proper situational awareness
If you want to see what changes have been made to SQLite, the timeline screen will give you an overview of changes for all branches, and you can open up as many details as you like. You can also check it from your smartphone while you are out.



On the other hand, GitHub and GitLab do not have equivalent functionality. The closest analogy is

a network graph , but it is slow to render and you can't see the details. The commit view provides more detailed information, but it can only display one branch at a time, making it tedious to see all recent changes.



Some Git users have installed third-party graphical viewers to display recent changes, but because they are third-party, they must be installed and managed separately, and Since the repository needs to be synchronized, it is not possible to easily check the project status on a smartphone.

2: Difficulty finding a successor for Check-in
When using Git, it's easy to trace back to what happened before a particular commit, but it's difficult to see how code has changed since a particular commit. It's not easy. Fossil has the ability to display all check-ins derived from a particular major release, making it easy to check branch status on the web.



Furthermore, Fossil's check-in information page has an item called 'Context', which displays previous and subsequent check-in information in chronological order, making it easier for users to understand the situation.



3: Git is too complicated
When developing using Git, you need to pay attention to all the items listed below.

・Working directory
・Staging area (index)
・Local head
・Local copy of remote head
・Real remote head


On the other hand, with Fossil, developers only need to think about the working directory and check-ins while they are working, freeing up more brain resources for software development.

4: Git doesn't track past branch names
Git maintains a complete

directed acyclic graph (DAG) of commit history, but branch tags are local information and are no longer synchronized after a branch is closed. This can make reviewing past branches a pain.

For example, let's say a customer asks you what happened to the previous 'prefer-coroutine-sort-subquery' branch, and you answer by looking at the history in your version control system.

In the case of Git, you can see that the last commit was on September 30, 2017, but it doesn't show you what happened after that, which is of little help when trying to understand what happened.



In Fossil, it is obvious that after the commit on September 30, 2017, it was merged into the 'trunk' branch, which is equivalent to main in Git.



Although it may be possible to display this information using third-party tools, the fact that you must use third-party tools to obtain the information you need is not very useful for core systems. They say it's not good.

5: Git is difficult to manage
Git is complex software and requires an installer to deploy Git on your workstation or upgrade to a new version. Also, since setting up a Git server is not easy, many developers use third-party services such as GitHub and GitLab to add dependencies to their projects.

Fossil, on the other hand, runs as a single standalone binary, so installation is just a matter of passing it through your PATH. In addition to Git functionality, a single binary includes GitHub and GitLab functionality, allowing you to use wikis, bug tracking, forums, and more. You can launch a Fossil community server in minutes, and it can operate in a lower spec environment than servers such as GitLab.

With less administration, developers can spend more time developing software.

6: Git has a bad user experience
Although Git has a huge number of features that allow it to be used in a variety of situations, only a handful of developers can actually master them. An exaggerated expression of how difficult Git is for many developers: ``To use Git, all you have to do is memorize and type a few commands. If an error occurs, save your work somewhere else and reset the project.'' There are many developers who find it difficult to use, as there is a satirical manga titled ``.

Developing software is difficult and requires a lot of concentration. A good version system should help developers, not frustrate them. Git has continued to improve since its introduction, but there is still a long way to go.

A detailed comparison of Fossil and Git can be found on the Fossil Versus Git page.

in Software, Posted by log1d_ts