It's basically plaintext. Even deltas are plaintext for text files.
Reason: "The global state of a fossil repository is kept simple so that it can endure in useful form for decades or centuries. A fossil repository is intended to be readable, searchable, and extensible by people not yet born."
Very interesting. Looks like fossil has made some unique design choices that differ from git[0]. Has anyone here used it? I'd love to hear how it compares.
I use Fossil extensively, but only for personal projects. There are specific design conditions, such as no rebasing [0], and overall, it is simpler yet more useful to me. However, I think Fossil is better suited for projects governed under the cathedral model than the bazaar model. It's great for self-hosting, and the web UI is excellent not only for version control, but also for managing a software development project. However, if you want a low barrier to integrating contributions, Fossil is not as good as the various Git forges out there. You have to either receive patches or Fossil bundles via email or forum, or onboard/register contributors as developers with quite wide repo permissions.
It was developed primarily to replace SQLite's CVS repository, after all. They used CVSTrac as the forge and Fossil was designed to replace that component too.
I use Fossil extensively for all my personal projects and find it superior for the general case. As others said it’s more suited for small projects.
I also use Fossil for lots of weird things. I created a forum game using Fossil’s ticket and forum features because it’s so easy to spin up and for my friends to sign in to.
At work we ended up using Fossil in production to manage configuration and deployment in a highly locked down customer environment where its ability to run as a single static binary, talk over HTTP without external dependencies, etc. was essential. It was a poor man’s deployment tool, but it performed admirably.
Used it on and off mainly to check it out, but always in a personal/experimental capacity. Never managed to convince any teams to give it a try, mostly because git don't tend to get in the way, so hard to justify to learn something completely new.
I really enjoy how local-first it is, as someone who sometimes work without internet connection. That the data around "work" is part of the SCM as well, not just the code, makes a lot of sense to me at a high-level, and many times I wish git worked the same...
> I mean, git is just as "local-first" (a git repo is just a directory after all), and the standard git-toolchain includes a server, so...
It isn't though, Fossil integrates all the data around the code too in the "repository", so issues, wiki, documentation, notes and so on are all together, not like in git where most commonly you have those things on another platform, or you use something like `git notes` which has maybe 10% of the features of the respective Fossil feature.
Email isn't a wiki, bug tracking, documentation and all the other stuff Fossil offers as part of their core design. The point is for it to be in one place, and local-first.
I like it but the problem is everyone else already knows git and everything integrates with git.
It is very easy to self host.
Not having staging is awkward at first but works well once you get used to it.
I prefer it for personal projects. In think its better for small teams if people are willing to adjust but have not had enough opportunities to try it.
Is it possible to commit individual files, or specific lines, without a staging area? I guess this might be against Fossil's ethos, and you're supposed to just commit everything every time?
Most people ditch GAFAM because they want to own their digital identity and not just trade one gatekeeper for another, even if it's "hassle free" to start off with.
And with the setup of Happymail renting out individual email addresses under the same domain to different users, it makes it impossible for them to leave the platform. Have you considered letting people own their domains?
Thanks for the thoughtful feedback, grenran. You're right that domain ownership is the gold standard for digital sovereignty. We considered it, but realized it creates the exact complexity we're trying to eliminate: DNS management, registrar renewals, deliverability issues, etc. That said, your point about lock-in is valid. Here's our thinking: Portability matters. Your emails are yours. You can export everything via IMAP anytime, no artificial barriers. If you leave, you take your data. We're not gatekeeping your identity. We're providing infrastructure. Think of it like renting an apartment vs. buying a house, both are valid, and renting doesn't mean your landlord owns your furniture. For power users who want domain ownership, you're probably better served by Fastmail, Migadu, or self-hosting. We're not trying to replace those. We're targeting people who just want firstname@lastname.re without learning what an MX record is. The tradeoff is real: simplicity vs. full ownership. We chose to optimize for the 95% who want email to "just work." But we hear you, and we're exploring options like letting users transfer their address to their own domain if they ever want to graduate to full control. Would that kind of "graduation path" address your concern?
Feel free to come up with a better example that uses the same basic pattern: someone online claims that they have prior experience with X and hence advises you to do Y.
The world has been full of snake oil salesmen since the dawn of time, all with a highly persuasive sob-stories.
If you rely on shortcuts, like anecdotes or 'credentialism' for those who profess to be experts, then you will get rolled over regularly. That's the cost of using shortcuts.
That information may be fraudulent and put forward by this season's Dr Andrew Wakefield has to be factored into any plan for using external sources.
