Skip to content
Tech News
← Back to articles

From Git to Fossil

read original get Pro Git (Apress) by Scott Chacon and Ben Straub → more articles
Why This Matters

A developer explains why they're moving personal projects from Git to Fossil, citing an early Git proposal to make Rust mandatory as the trigger. It's a small but telling data point in the broader C-to-Rust debate now touching foundational infrastructure tools, and a reminder that language choices carry community and dependency consequences for downstream users.

Key Takeaways
Worth a Look

Pro Git (Apress) by Scott Chacon and Ben Straub — Whether you're sticking with Git or shopping around for an alternative like Fossil, it helps to really understand the model you're leaving behind. Pro Git walks through branching, merging and repository internals in plain language, making it easy to compare workflows across version control systems. A solid desk reference for anyone rethinking their personal project setup.

See Pro Git (Apress) by Scott Chacon and Ben Straub on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

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