So, it's a git server with an interesting storage layer? Don't get me wrong, that part sounds like it might have been a ton of work to implement, but I think the web UI (pull requests, etc) is a lot of what Github has won on historically.
Basically I don't feel qualified to judge the product itself, but I think positioning it against Github, while popular given the recent hard times, isn't quite correct.
"Doesn't" doesn't mean "can't". Someone just needs to do the work (with no thanks or pay expected).
edit: the perspective of open source projects has really changed in the last 10 years, from collaboration to nice personal projects now being referred to as "the product".
So the only real reason is you already have a postgres server and want the efficient query indexes.
As an interesting side note. I found this document on the internal data structure of fossil. https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...
I'm not saying this project isn't cool, but whenever you have ANY software that's designed to be hosted A-style, and you host it B-style, the obvious question is "Why not host it the A way?"
Along those lines, even zlib could probably be skipped if the underlying filesystem is a compression capable one. ZFS can, though there are probably others as well.
Having no web UI, at least even a rudimentary one is kinda a bummer though.
- Gitea's (I use Forgejo) reliance on disk storage for `.git` is perfect for me because files are well understood as a concept by most people. (To be clear, Gitea/Forgejo stores non `.git` artifacts in PostgreSQL.)
Every battle hardened linux tool knows how to backup files. Plain old `rsync` can backup and restore files. I have heard people put their `.git` on something like Dropbox and have tit work both for sync and backup (I've never tried it myself).
You can run checksums on files and ensure they are exactly how you expect them to be.
There are multiple, well tested, well understood options to reliably backup, snapshot and restore files.
Also, remote/cloud storage for files is really cheap. In most cases, if it's less than 10GB, you likely don't have to pay anything at all, as in $0 every month for having a backup on servers that won't go up in flames even if your laptop or house did.
- OTOH, PostgreSQL backup and restore feels like they are less popular or accessible to the general population vs files' backup and restore.
Infact, for non DBA folks who don't necessarily understand PostgreSQL WAL, backup snapshotting, what asynchronous and synchronous WAL replication means and how they affect RTO and RPO, there are definitely multiple and non-obvious ways to get more things wrong than right, and lose your data - something you wouldn't have to worry about when using files backup and restore.
> Whereas with this, I could just handle it as part of the database backup process
What's the database backup and restore process you follow right now and what are the tools you use?
There are fossil hosting sites, which is probably what you are talking about. I don't use one but here is an example. https://chiselapp.com/
But fossil itself can already serve many projects acting like a self contained fossil hub.
The core model objects in git are all pretty straightforward and their interactions well defined.
