upvote
> 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.

Hmm that's interesting to hear. I'm starting up a very small business this year (one guy selling shit at a craft fair booth) and I'm using plaintext accounting files in a Git repo for it. I wonder if Fossil could keep me from re-inventing some note taking and record keeping approaches. I'll have to look into what it can do.

reply
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.

reply
Fossil is very easy to self host. If you already have a web server it needs maybe 10 or 15 lines of server config. If you want to avoid start up you need something to autostart/restart the server process. If you point it at a directory you can add a new repo simply by adding a Fossil file to the directory.

You can even run it on shared hosting as a CGI (never done it myself).

The only thing that took some setup was sending email notifications.

> 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.

I agree I use Fossil for multiple personal and small projects. Anywhere I can, really. It is very simple and everything is distributed.

reply
You should continue with a name which is related to fossils, fossillab.io, boneyard.dev and so on…
reply
fossilised.dev .. maybe british spelling.

palaeontology.dev ... too awkward.

museum.dev has a sort of "this is dead" ring to it.

Ironically what fossils are stored in within a museum is referred to as a "repository"..

Well, there's only 2 hard problems in computer science right?

reply
The best know hosted Fossil service is https://chiselapp.com/
reply
Yeah, museum sounds like dead and rot… However on my small site [1] that’s the name of the fossil repos page

[1]: https://hdrz.cc/museum

reply
> what fossils are stored in within a museum is referred to as a "repository"

I own a cute domain for that: repositoryum.com. I had the plans for it, but it's one of those that never came to a realization.

reply
Maybe something fossil-adjacent:

- amber.dev

- quarry.sh

You’ll probably need to play with gTLDs to find something that works.

Can also echo “scm” from fossil’s domain:

- amberscm.dev

Along with useX.com, Xhq.com, etc., patterns.

Of the two you have listed, I’d choose fossilforge, but would vote for an alternative TLD since .io has an expected meaning coming from GitHub.

reply
Or, hear me out, we learn to host our own shit again and stop giving all our data to $megacorp after the inevitable buyout.
reply
For me it was Mercurial, but yeah, being done by Linus and adopted in the Linux kernel was the killer feature for Git's adoption.

If Git was created by a random dude, it would never taken off.

reply
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

reply
Those screenshots and videos are taking up space SOMEWHERE, whether it be your inbox or your filesystem, why not have them as unversioned artifacts in your db? (Fossil supports this). Of course if you have multiple people working on it and many assets, other solutions would be better (shared cloud drives, etc). But for my use case of a storing textual information only (and perhaps a demo video, which many Git users often keep a video in their source and link it in the readme), Fossil works great to keep all my stuff together in the same context.

I explicitly dislike the idea of using Git as the backing store. Forget the fact that Git is not native on Windows and is immensely bloated; the actual .git folder is a mess for backup systems when working locally compared to a single database file.

reply
> Those screenshots and videos are taking up space SOMEWHERE,

Sure but there is a big difference between being stored once (modulo backups) on a central server, and every developer needing to download all the resources for every issue and the entire wiki in order to work on the code at all. It works fine for sqlite, because they only have a handful of developers, so it's not a big deal for them each to have their own local copy of everything. But having to download GBs of issue and wiki data in order to make a pull request (however that would work with fossil) or otherwise contribute is a significant barrier to entry.

reply
I haven't checked but surely you can only check those out if you need them?
reply
Not without having a degraded git experience like shallow clones, or using hacks like LFS or Xet, and then you're back at the initial problem of depending on "something else besides your repo".
reply
as far as I can tell, fossil doesn't support that. but I could be wrong.
reply
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.

reply
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)
reply
> 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.

reply
My first distributed VCS was Tom Lord's Arch. I may have started early, but it took me a long time to understand distributed version control, thanks in no small part to Tom Lord, lol. GNU.
reply
Same, then moved to bazaar which was really easy and nice.

Of course moved on to git but I still think bazaar did many things better.

reply
I'm still using Mercurial whenever I can (including work!). The Tortoisehg GUI is good for doing reviews, and the command line is comfortable.

I grew up on CVS and then Subversion. Played with Bazaar a little, mainly because it could use an SFTP location as the back-end.

And I still avoid Git if I can help it. I would/do figure it out when I have to, but it never feels comfortable. Such is my avoidance that I'm dabbling with Jujutsu although I'll still need to really sit down and read through it some more to grok the way it works.

reply
You might like pijul if you like darcs
reply
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.

reply
You can link the commit with the ticket by including its hash in the commit message, and then mark the ticket as fixed. See here:

https://stackoverflow.com/questions/5761669/how-to-fix-a-tic...

reply
This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.

Personally speaking though, I don't want things automagically closed GitHub-style based on parsing a check-in comment. An issue ought to be closed with intention.

reply
> I don't want things automagically closed GitHub-style based on parsing a check-in comment.

Sure, I get that. I was just disappointed that none of the project management stuff seemed terribly integrated in any way from my brief review. It seemed like opportunities there that were not taken.

reply
I wanted to host our company wiki in Fossil, but there is no way to import it because Fossil completely separates versioned project docs and the built-in Wiki function. Our git-based wiki could be imported into Fossil as "docs" but would not receive the nice formatting, GUI editor or dedicated page that the Wiki function does. There is also no benefit to manually converting it all to Fossil Wiki as some of our wiki editors work on raw markdown.md files and commit changes by git which is not possible with the Fossil Wiki; everyone would be forced to use the online editor only, whereas currently we have a choice of markdown or Gitea's editor.
reply
Found a link to the Fossil forum thread I opened about this very problem of the split between Fossil Wiki and docs:

https://fossil-scm.org/forum/forumpost/e19ed2bfea94fc91f544c...

reply
Now is a great time for somebody to buy fossilhub.com and create a new community.
reply
I know someone[0] who is working on exactly this right now: https://fossilrepo.io/

I don't think he's got public sign ups turned on yet. Maybe hit him up on the Twitter for more info.

[0] - https://x.com/ragelink

reply
There's also "Chisel - Fossil SCM Hosting".

"This service is completely free and run because a service like it should exist."

https://chiselapp.com/

"All public repositories":

https://chiselapp.com/repositories/

I don't know if it has all the GitHub features people may be looking for.

Chisel runs on Flint, "The ISC licensed codebase behind http://chiselapp.com.":

https://chiselapp.com/user/rkeene/repository/flint/index

EDIT: Add "...should exist." sentence from the homepage.

reply
This appears to be down.
reply
I already saw fossilhub.io mentioned in this thread, actually.
reply
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.

reply
> in theory yes, in practice no

Why? I don’t see any practical reason.

reply
I wonder what tradeoffs make Git faster for large repository. Though for a long time that excluded large blobs.
reply
None, it just received the help of the vast majority of well-payed SWE to make it that way
reply
Git has format dedicated for storing snapshots of trees and diffing them, fossil just uses SQLite and few tricks to keep size small
reply
Of tree, or of sub-DAG?

"Just use SQLite" feels like missing the forest for the tree (the pun being coincidence here). That is, certainly any database out there already use all kinds of very efficient structures to walk graphs under the wood.

Maybe Git has a more bespoke approach to its specific goal of source code as main topic to deal with, and finner layer of abstractions. Which could also explain the clumsy leaky interface it presents.

reply