Re-discovering Fossil

Sometimes I consider myself more of a commit messages-author than an iOS developer. I have used git for my entire programming career. It's not my SCM of choice because I deliberately chose it but it was the tool used by the teams I joined in university and in my first job.

git is not a simple tool at all, it is complicated and complex and easy to screw up but it gets the job done. It took me some time to learn, I still prefer GUI-clients over CLI-tools. After more than a decade of using it, well, I'm used to it. I found my ways around and I even value certain aspects of git and its ecosystem, be it collaborating with myself or others and sharing knowledge (read: Git[ea|hub] and Pull Requests) or for cleaning up my work (read: Rebase and git add -p). The way I usually work is like this:

1. Do some work and/or make some progress
2. Remember that git exists and split the work into clean pieces using git add -p so that it makes sense.
3. Go to 1.

Sure, nobody sees my mistakes, but up until now I considered it way more important for others to understand quickly how I solved a problem and not how I did notsolve it. Commits are public, but my stashes are my dirty little secrets. And I have a lot of stashes.

Last year, someone collected some fun facts about SQLite (via Mastodon) and this is how I rediscovered Fossil. I do that once in a while but this time I've gone down a little rabbit hole — I even listened to an interesting podcast episode!

Fossil is a SCM written by the same author as SQLite, Richard Hipp, who didn't find a tool to fit his team's needs and work on SQLite and decided to write his own SCM, backed by SQLite. This is how Fossil was born.

But Fossil is more than a plain SCM, it brings its own Wiki and Issue Tracker, for instance. I consider Fossil a very elegant tool and sometimes I wish it would have been the SCM of the teams back then. git was written to support Linux development, and Fossil was written to support SQLite development. In other words: It targets a different audience with a different way of working compared to git. People working closely together. People knowing and trusting each other, for better and for worse. But git, being basically an industry standard, is everywhere, even when Fossil would be a worthy alternative. Rediscovering it has made me think about how I use git — and more importantly: Why this way?

Why do I feel the need to clean up my work? Why do I feel ashamed of my mistakes and knowledge how things do not work? But also: How can I model the pieces that haven proven useful and valuable using Fossil, like PRs? People make mistakes, but countless of my mistakes didn't make their way into a codebase just because someone else had a look at my code. Sure, you can discuss a branch in a Fossil-ticket and merge it afterwards, but PRs are just damn frictionless. Am I this used to git that I cannot think of other ways to work?

I'm fascinated with some design decisions of Fossil. For example, it doesn't come with rebase — for a reason:

It is dishonest. It deliberately omits historical information

Honesty seems to be a key concept of Fossil. And so I decided to give it a try — and hopefully grow with it. For now I'm using it for a little SwiftUI-project, I commit my code, write tickets and use the Wiki to take notes. In the end, I'm not just a commit messages-author, but also a freelance iOS developer you can hire in Germany.