From Git to Fossil

Recorded: Sept. 13, 2026, 3 a.m.

Original

Summarized

/home/lucio.albenga.es - From Git to Fossil

/home/lucio.albenga.es

🇪🇸 ES |
🇬🇧 EN

From Git to Fossil

Published on
2025-11-12

People at Git has started to work on a proposal to make the Rust1
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 documentation2 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.
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.
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.
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.
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 Git3
one (this is the functionality used by Fossil and Sqlite projects to
manage their GitHub mirrors).

Taking all this into account, I decided to install Fossil and switch my
projects from Git. Below you'll see how to do it.

Installing Fossil

The first step is to install Fossil and it's quite likely that the
package manager of your operating system already has it available:

sudo apt install fossil # Devuan GNU+Linux
pkg install fossil # FreeBSD

Once your package manager ends the installation you can check its
availability with the following command:

fossil version

The command above should return something like the following:

This is fossil version 2.21 [3c53b6364e] 2023-02-26 19:24:24 UTC

Importing Git repositories

Fossil's documentation4 has the following example to export a Git
repository and import it as a Fossil repository:

cd repository
git fast-export --all | fossil import --git repository.fossil

I did it differently because I wanted to adjust some things to have
the imported repositories "right". As I have several repositories I
created two different folders, one, git-exported, to store the exported
repositories and another one, fossils, to store the new Fossil repositories:

mkdir ~/git-exported
mkdir ~/fossils

Now you can get into each Git repository folder and export it:

cd repository
git fast-export --all > ~/git-exported/repository.export

Once you have exported all your Git repositories you should go
inside the ~/fossils folder and import them one by one with the command:

fossil import --git \
--rename-master trunk \
--attribute "your@mail.com your_username" \
repository.fossil ~/git-exported/repository.export

The --rename-master trunk option renames your Git master branch as
trunk in your new Fossil repository. Fossil, like other version control
systems such as Subversion, uses trunk as the name of the master branch.
If you are among the unfortunate ones who have their master branch named
as "main" this option is not for you and you should check Fossil's
documentation if you want to rename it.

The --attribute "your@mail.com your_username" option changes the
email address "your@mail.com" from Git commits to "your_username" in
the imported Fossil commits. In Fossil the default username is the same
as the one you're currently using in you operating system. Obviously
the given email address should exist in one or more commit messages.

If you want to change more than one email address you can do it
using several --attribute options:

fossil import --git \
--rename-master trunk \
--attribute "your@mail.com your_username" \
--attribute "rms@gnu.org rms" \
--attribute "linus@kernel.org torvalds" \
repository.fossil ~/git-exported/repository.export

The output of the import command looks like the following:

Rebuilding repository meta-data...
100.0% complete...
Vacuuming... ok
project-id: e64b112b40eb3db188060ddb8deeaa96a6ad3b71
server-id: bfbcd4bf8f0f64eaa2d832ddc3b4af00639624a6
admin-user: your_user (password is "XAxPVZcNQ6")

If you look closely, the output gives you the repository
administrator's user and password. Keep it because you'll
need it to do certain things on your repository.

Setting Up a Fossil Server

Fossil has an embedded web server so you can take advantage of it to
create a self-hosted server quickly and easily. The following method
is enough for a system with few users, in a private network that
cannot be accessed from the outside. There are different ways to set up
a Fossil server and some are better than others depending on your
needs, so I recommend you to check out the official documentation.

First you should create a folder to store the Fossil repositories on the server:

mkdir /path/to/your/fossils

Next copy your "fossils" to the folder on the server:

scp *.fossil user@your_server:/path/to/your/fossils/

Now you can start the server with the following command:

fossil server --port 8043 \
--cert /path/to/your_cert.pem \
--pkey /path/to/cert/key.pem \
--repolist /path/to/your/fossils/

If you don't have a valid certificate you can use the follwing
command:

fossil server --port 8043 \
--cert unsafe-builtin
--repolist /path/to/your/fossils/

Once the server is running, if you put the following url
https://server_address_or_hostname:8043/ in your browser
you'll access a web page with the list of your repositories.
If you click on one of the repositories listed, you'll see the
repository web page. In the navigation menu you should see a
"login" option. Click on it and use the repository administrator's
username and password. Now you can configure the repository to your
liking. Check out Fossil's documentation to learn more.

If you lost your Fossil repository administrator's password, you can
recover it by following these steps:

Go to the repositories folder in your server
If you don't have Sqlite installed, install it following
the usual method of your operating system.

Open repository.fossil with Sqlite:

sqlite3 repository.fossil

Once inside sqlite execute the following query:

select login,pw from user;

The query above will return something like:

The password is the value on the second column
(in this example the string My3w2jRxt1).

Exit Sqlite with the following command

.quit

Using Fossil

Here is a very brief guide on how to start working with Fossil.
This guide assumes that you know how to use Git, at a very basic
level, and it's just a starting point, so I recommend you
to read Fossil's documentation and the Fossil Book5.

Getting Help

The help command is essential to see which commands are available and
the uses and options of each one of these commands. The help command
works just like Git:

fossil --help
fossil command_name --help

Creating and cloning repositories

These are similar to Git's but with differences. In Git it's usual that
the repository matches the current working folder. In Fossil this is not
so, there is a clear separation between the repository, file
repository.fossil, and the working (check-out) folder repository_folder.

Creating a repository

You can create a new repository with the command:

fossil init repository.fossil

This command will create only the repository, i.e. the file repository.fossil.
To start working with it you have to "open it". Create a folder, move inside it,
and open the repository:

mkdir my_working_folder
cd my_working_folder
fossil open /path/to/repository.fossil

You can also tell Fossil the name of the working folder and if it does not
exist Fossil will try to create it:

fossil open --workdir my_working_folder /path/to/repository.fossil

Cloning a repository

You can clone a repository using the command fossil clone followed by the
repository url. The url can be a web url, a ssh url, a file path, etc.:

fossil clone https://host/repository

This command will automatically download the file repository.fossil
and it will create, at the same level, the working folder repository_folder.
If you don't want it to create the working folder you can do it by using the
command like:

fossil clone --no-open https://host/repository

Once the repository is cloned, if you want to send your commits to the
remote repository (and you have permissions for it), you should configure
inside the working folder the remote fossil repository:

fossil remote https://user@host/repository

The command above will asks you for your user's password and it will
also asks if you want to save it for future use.

TIP: Because Fossil has this clear separation between the repository file
on one hand and the working folders on the other, I keep all the
*.fossil files inside a folder named fossils in my /home and
I have the working folders where is most appropiate in each case.

Getting Info

For getting the information about the working folder and repository status
there are some differences compared to Git, especially in the name and use
of the commands.

Viewing the timeline

In Fossil the fossil time and fossil timeline commands are the
equivalent of Git's git log command. Here are some examples from
the one that provides less information to the one that provides more:

fossil time --oneline # similar to git log --oneline
fossil time
fossil time --medium
fossil time --verbose # similar to git log

Viewing changes in your working folder

To see the changes in your working folder compared to the repository
there are several commands and each one of them has different options.

To see which files and folders are not under version control:

fossil extras

To see files that are under version control and have been modified:

fossil changes

To see a combination of the two previous commands:

fossil changes --differ

To see the working folder and repository status in a way more closely
to the output of Git's git status command:

fossil status --differ

Viewing the Diff(erences)

To see the differences between the contents of our files in the working
folder and what is in the repository, Fossil, like Git, has a diff command:

fossil diff

To see the differences between a specific commit and the working folder:

fossil diff --from 2c26dd6b69 # 2c26dd6b69 is the hashtag of the commit

To see the differences between two specific commits:

fossil diff --from 2c26dd6b69 --to cd086a1045

Fossil's diff command doesn't show colorized diffs. Check out
the Wiki if you want colorized diffs6

Getting changes

Fossil has an option called autosync that is enabled by default. This
option keeps your local repository synchronized with the remote repository.
If you have the autosync option enabled, you can get all the changes from the
remote repository (if any) with the command:

fossil update

Otherwise it would be more similar to Git's. You have to do
first a pull to get the changes and then an update for
these to appear in your working folder:

fossil pull
fossil update

Commiting changes

As Fossil does not have the staging area, the commit is much more
likely to version control systems like Subversion than Git.

If you want to make a commit with all the pending changes:

fossil commit

The command above will open an editor for you to enter the commit
message, but you can also provide the commit message as an option:

fossil commit -m "My commit message"

You can commit specific files with:

fossil commit file1 file2
fossil commit file1 file2 -m "My commit message"

If you have the autosync option enabled, the commit command will also
send your changes to the remote server (if any). Otherwise you'll have
to send the changes to the remote server with the command:

fossil push

Adding and deleting files

When you need to put new files under version control you can do it with:

fossil add filename

If you want to remove a file from the version control you can do it with:

fossil delete filename
fossil rm filename

By default the rm and delete commands do not physically delete the file
from the file system, they simply mark it as no longer under version control.

There's also a command fossil addremove which adds to the repository all the
files in the working folder that are not under version control and removes
from the repository all the files that are under version control but that
no longer exist in the working folder.

Ignoring files

Configuration is one of the points where there are several important
differences between Fossil and Git, so I recommend you to check out
Fossil's documentation. To ignore files and folder you have to create
the file .fossil-settings/ignore-glob inside the working folder:

cd working_folder/
mkdir .fossil-settings
touch .fossil-settings/ignore-glob

Then edit it using glob patterns7:

build/
3rdparty/
*.o
*/a.out

Branches and Tags

Git's paradigm encourages an intensive use of branches and tags but
Fossil's paradigm and features are different so the workflows are
different too.

As I don't make much use of branches in my personal projects, I
think that in order for you to get an idea of the differences so that
you can adapt Fossil's features to your workflow, or your workflow to
Fossil's features, you better read the following links from the Fossil Wiki:

Fossil Check-Out Workflows
Fossil Branching, Forking, Merging, and Tagging
Fossil Private Branches

Local web interface

I don't want to finish this little Fossil guide without making it
clear that you can access and use the web interface without having
a Fossil server. To do it, run the following command from within
the working folder:

fossil ui

Final Thoughts

I like Fossil very much and, in my opinion, it's an almost perfect mix
between a centralized version control system like Subversion and a
distributed one like Git. I like how easy is to put it in server mode,
its web interface and, above all, the simplicity of its command line and
of the most common tasks.

I think it's a great program that has a lot to offer, especially to
indie programmers and small groups who are interested in self-hosting
solutions. If you are looking for a simple and effective alternative to
Git do not hesitate to take a look at Fossil because it may be exactly
what you are looking for.

Footnotes:

1
Git Mailinglist [PATCH RFC 0/3] Introduce Rust and announce that it will become mandatorty

2
Fossil's Wiki

3
How To Mirror A Fossil Repository On GitHub

4
Import And Export To And From Git

5
Fossil Book

6
Fossil Colorized Diffs

7
Fossil File Name Glob Patterns

Website made and updated with Free/Libre Software. Checkout the changelog.

::Member of::

The author initiated a consideration for switching away from the Git version control system, partly due to dissatisfaction with the Rust community's focus and perceived dogmatic approaches to project development. Having experience with various version control systems, the author explored alternatives, ultimately choosing Fossil based on its structural and operational features. Fossil was selected because it is implemented in C, making it a small and efficient program that consumes minimal hardware resources. Furthermore, Fossil offers a simpler interface compared to Git, lacking "overkill" functionalities like a staging area which the author deemed unnecessary for their personal projects. A key advantage of Fossil is its capability to facilitate quick and easy self-hosting, as it includes a built-in web server and interface for version control views, wikis, and tickets, eliminating the need for external dependencies like GitLab or Gitea. Additionally, Fossil handles commit authorship by using usernames instead of email addresses, mitigating issues related to email spam in public repositories.

Fossil demonstrates interoperability with Git, supporting the ability to revert to Git if necessary and handling two-way synchronization with Git3 repositories, which is relevant for managing GitHub mirrors. The process of migration from Git to Fossil involved exporting existing Git repositories using git fast-export and then importing them into Fossil using fossil import. This required careful handling of repository metadata, specifically renaming the master branch to trunk and modifying commit author attributes to map Git email addresses to usernames within the Fossil system. The import process provides administrative credentials for the new Fossil repository, which are necessary for later configuration.

To utilize Fossil effectively, a self-hosted server setup can be established by leveraging its embedded web server. This involves copying the Fossil repository files to a server directory and then starting the server with specific command arguments defining the port, certificates, and the repository list. Access to the repositories is managed via a web interface, which requires administrative login details. Password recovery for the repository administrator can be achieved by interacting with the underlying SQLite database to retrieve the stored credentials.

Fossil provides a distinct approach to repository management and interaction compared to Git. While similar commands exist, Fossil operates with a clear separation between the repository file and the working folder. Repositories are initialized with fossil init, which creates the repository file, followed by opening it within a working directory structure using fossil open. Cloning repositories uses fossil clone, which downloads the repository file and creates a corresponding working folder. Changes are tracked using commands like fossil time, which serves as an equivalent to git log, and fossil diff, which allows for comparing file contents between the working folder and specific commits or between two commits.

For managing changes, Fossil employs commands like fossil commit, which can handle committing all pending changes or specific files, and fossil push to synchronize with a remote server. File additions and removals are managed through specific commands like fossil add filename, fossil delete filename, or the combined fossil addremove command, which handles adding or removing files based on their status in the working directory. Ignoring files is managed through a configuration file within the working folder, utilizing glob patterns to specify files and directories to exclude from version control. Furthermore, Fossil supports concepts of branching and tagging, though the author recommends consulting the Fossil Wiki for details regarding its specific workflows, as these differ from Git's paradigm. An optional local web interface can be accessed directly from the working folder using the fossil ui command, allowing interaction without a dedicated server running. Ultimately, the author views Fossil as a beneficial hybrid, balancing the centralized nature of systems like Subversion with the distributed nature of Git, positioning it as a simple and effective alternative, particularly appealing to independent programmers and those focused on self-hosting solutions.