I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets<issues>, etc) are just so useful to have versioned with your code in one file.

I use Fossil for all my freelance work and it so easily allows me to get right back into the context of a project, niche details and agreements had with a client, etc. No need to pollute the codebase or gather together a million emails or notetaking software just to get back up to speed.

It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch. Fossil makes it super easy to switch and the workflow is actually easier coming from Git.

Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it.

Two things I keep coming back to: (1) The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fighting it. The 5,000-engineer monorepo market is a solved problem (Git won). Fossil should own the 1-50 person bracket — where having issues, wiki, forum, and code in one self-contained, syncable SQLite file is a huge unfair advantage.

(2) AI agents are a brand-new reason to look at Fossil that didn't exist when Git won. Every repo is a queryable SQLite file. An agent reads tickets + wiki + code + history with one SELECT — not 47 GraphQL calls and a rate limit. RAG and MCP setups against the repo become trivial.

We're stuck on the name (fossilforge vs fossilhub). If you have an opinion: https://fossilhub.io | https://fossilforge.io — vote, get early access.

The self-hosted side is already shipping at fossilrepo.io if you'd rather run your own.

--- Disclosure: founder, so grain of salt accordingly.

You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews.

It just... never was something majority actually want so they didn't really get any traction.

Issues wise you also get few nasty cases where you really do not want to keep it with project, like having clients send a bunch of screenshots or even videos of triggering some bugs can grow storage pretty quickly... and while extra few GBs on a file server isn't a big deal, keeping it with code repo just so someone can look at tickets locally is PITA, and you quickly get into "let's not use it, it just makes everything complicated and everyone repo bloated".

Someone could probably implement most of fossil features using git as backing store without all that much problems, the wiki/issues/whatever else features would just be separate, parallel branch hierarchy

I feel like part of that was timing. IIRC, when git was already stable and usable as a daily-driver, Fossil was still sometimes requiring that you completely recreate your repo when updating to a new version.

Git certainly had (and perhaps still has) worse user experience, but it worked and felt production-ready, with, of course, one of the largest open source projects in the world using it, and that made all the difference, perception-wise.

> It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch. Fossil makes it super easy to switch and the workflow is actually easier coming from Git.

I was exposed to Mercurial before Git and I stubbornly tried to advocate for it over Git for a while. BitBucket, at the time, gave Github a good run for their money and had great Mercurial support and was what I preferred.

I'm not really sure VCS were ever differentiated for there to be a wide world of them. They all solved the same set of problems so similarly that it felt, to me, that there had to be one winner. Right now most of the competition is in the Git Porcelain space.

N.B. I actually have a soft spot for darcs, which was my first actual DVCS. I just loved it so much more than svn and refused to use svn in college and used darcs to actually manage my projects and push them to svn after.

Part of the problem is that fossil is very opinionated. It's great if your development flow is similar to that of the sqlite team. But it is very difficult to get it to work for other workflows. And in particular, fossil is designed for use by small teams and isn't really designed to be used by large organizations. This is even explicitly mentioned in the "Fossil versus Git" page (https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)

When I tried Fossil it had things weirdly separated.

I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.

Now is a great time for somebody to buy fossilhub.com and create a new community.

I think this shows that you do not consider all build-up options here. Let me explain that.

Could something like github be made with fossil, aka fossilhub?

I believe the answer is ... in theory yes, in practice no. So this already means, if correct, the comparison between git and fossil is incorrect here. Fossilhub would not have dominated; git + github on the other hand did. Again, in theory a fossilhub could win over people to use it (and fossil), but people will compare it to github (back when github was still great) and become quite critical when fossilhub does not offer the same or similar set of functionality. At the least the core functionality - great issues + discussions, easy committing and changing of code and so forth.

Perhaps with enough resources, fossilhub could have conquered the world, but for whatever the reason, it did not, and I think this is in part due to the design. GitHub changed how people interact with repositories. They even made it easy to e. g. add files and change them online, at a later point in time. For instance in one project I am a co-maintainer and I rarely have to use the commandline; I can simply edit via the browser as it is. I don't think fossilhub would have done the same - actually, there is not even a fossilhub, so how would you want to compare git to fossil? It's not just the commandline code. Git has github; while it is a separate project, what does fossil have that people know and use?

> It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch.

We all have our dreams. All desert to become forests or agriculture may be a great idea. Effecting this is hard - but best luck to you betting on fossil here. I don't see it happening. Git raised the barrier here, even if only indirectly via github.

I wonder what tradeoffs make Git faster for large repository. Though for a long time that excluded large blobs.