From Git to Fossil
Published on 2025-11-12
People at Git has started to work on a proposal to make the Rust programming language mandatory. I don't like Rust and, above all, I don't like its community of little extremist characters who are trying to make everyone swallow their crap by rewriting projects that have been working for decades, doing social media brigading, and other nice little gems worthy of any tiny group with totalitarian delusions. That's why when I see that a project aims to "force" the use of or the switch from C to Rust, to the extent of my possibilities, I flee from it as if I were pursued by the Balrog of the Lord of the Rings with his whip.
I'm old enough to have used (or tested) many version control systems: RCS (Revision Control System), CVS (Concurrent Version System), SVN (Subversion), HG (Mercurial), BZR (Bazaar), and the aforementioned Git, which means I have no problem in switching again, so I started to think about a Git substitute for my personal projects.
The options were to go back to one of the already known or look at something else, and I remembered Fossil. I started looking over the source code and reading the official documentation to learn its features, its dependencies, how to install and configure it, etc., and I noticed it had many things I like:
It's made in C (although it uses some js and tcl for its web functionality) and is a small and efficient program that consumes few hardware resources.
(although it uses some js and tcl for its web functionality) and is a small and efficient program that consumes few hardware resources. It's simpler to use and it feels more natural (at least for someone who knows other systems such as Subversion) because it does not contain overkill functionalities such as the staging area, which may be useful in large and complex projects such as the Linux kernel, but for me they have no practical use.
(at least for someone who knows other systems such as Subversion) because it does not contain overkill functionalities such as the staging area, which may be useful in large and complex projects such as the Linux kernel, but for me they have no practical use. It allows you to self-host a server on your own quickly and easily because it is already prepared for it. In fact it has a web server and a web interface with version control views, wiki, tickets, etc. On the other hand, with Git you have to use an external software such as GitLab, Gitea or Forgejo, and each one of them is at least one extra software dependency.
because it is already prepared for it. In fact it has a web server and a web interface with version control views, wiki, tickets, etc. On the other hand, with Git you have to use an external software such as GitLab, Gitea or Forgejo, and each one of them is at least one extra software dependency. Commit messages don't use email addresses , they use user names so if you have a public repository you don't have to be worried about spam and you don't need a specific email address for this use only.
, they use user names so if you have a public repository you don't have to be worried about spam and you don't need a specific email address for this use only. It's interoperable with Git in the sense that if there is a need to change a repository back to Git you can do it and it also supports two-way synchronization between a Fossil repository and a Git one (this is the functionality used by Fossil and Sqlite projects to manage their GitHub mirrors).
... continue reading