alt Hacker NewsFossil versus Git
Comments
> Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, a web forum, and a chat service [...]
I like the idea of having all of those within the actual VCS, mostly because with Git you need centralized services like GitHub to provide that.
But I have to ask: Is it really a good idea? Seems like feature creep motivated by the wants of a single project (SQLite).
All of those could be (albeit awkwardly) backed with a git repo and a cron job. Wiki? Just make a repo with a bunch of Markdown or this-week's-favorate-markup-language files. Ticketing & bug tracking? Again, just a Markdown file for every ticket. Embedded documentation & technical notes? Those are just special wiki pages with different attributes. Forum and chat service? Do you want your VCS to do that? I get being able to hyperlink between files and conversations, but still.
It still looks _exactly_ the same way as a decade ago (well, there were some CSS tweaks). I used to use it for my own projects until friction overcame my tastes, but I remember one of the things I really didn't like about it was that the web interface was _so_ dated. I love Gitea because it feels a lot like GitHub (and hence I don't have to remember where things are).
Edit: Wow, it supports markdown now? and a forum? OK...
I was tinkering with writing my own .git parser recently, and I couldn't help thinking "this could've been an sqlite db".
I found https://github.com/chrislloyd/git-remote-sqlite as a way to achieve git-on-sqlite, which works by registering itself as a git "remote" helper.
Amusingly there exists a "Why SQLite Does Not Use Git" article (https://sqlite.org/whynotgit.html), but there is no corresponding "Why Git Does Not Use SQLite".
Brings me back... I did use Fossil in 2010, cf my notes on https://fabien.benetou.fr/Tools/Fossil but like most I only switched due to the popularity of git, not because any specific feature was missing.
fossil is really cool for the simple fact that you get your issues, tickets and wiki all stored in an SQLite DB. Feels neat and I wish I had more occasions to use it.
I actually use fossil all the time for my projects. It just makes more sense to me in the way it works and the ease of use. And you can self host your repos with ease, for example [1]
The infrastructure around fossil and jujitsu are missing. Git isn't the best but network effects matter. For example, we use jenkins at work and there is no plugin for fossil or jujitsu. Every customer we have uses git so we can't even propose fossil. Even though we might use only 10 git commands, those commands are universally known by all to work if something goes wrong. It isn't sufficient to say that fossil or jujitsu are better. The ecosystem and mindshare for an alternative DVCS is significantly lacking unfortunately.
I would not want to use fossil at work and I do not know if it could handle projects of that size. Would require manyears of rewriting tools that would not be realistic.
For my hobby projects I have used fossil for several years. It works great and I do not miss anything from git. It's simpler and just nicer to use.
If nothing else I felt like using the same version control system for over 10 years was getting boring. Needed something new to play with. See things from a new perspective. Like playing with a new programming language now and then, even when it is something I do not expect to get much real use out of.
> 2.6 One vs. Many Check-outs per Repository
For practical cases `git worktree` allows to have multiple checkouts. Document marks this section as "partly disputed" with an external link. IMHO git worktrees has the same ergonomics as in fossil. This section kinda discredits the rest of the article.
Fossil has some really nice ideas (although I don't like the feature bloat), but when I tried to use it I ran into so many issues and/or bugs. With git on the other hand I can't remember ever hitting a bug in decades.
I don't really like git that much, but it works pretty well most of the time.
If you want to understand the implementation, the DeepWiki documentation is very helpful:
> Commit first
pre-commit hooks?
Also, what are they talking about with "POSIX systems", is this a really old SCM? I've been using git natively on Windows for so many years, I don't remember how many.
Either way, any new SCM needs to interoperate or easily convert git repos if it wants mass adaption. I don't think git is programmatic enough, it can get really obese really fast (even with pruning/gc), it would be great if client-side "plugins" were a thing pushed by remotes (for things like secret scanning, linting), and I do agree that something like sqlite as a back-end would suit it better for performance. I would want newer gits to really be thought as more than an SCM. People are using it to manage all kinds of state. You can run countries with the dam thing! :), and some are trying.
I've thought about distributed-ledgers using git too, with or to replace block-chains.
One check-out per repository Many check-outs per repository
There are Git work trees so I can make many checkouts per repository.
Fossil is my goto Customer Documentation tool, Code, Wiki etc all in one file that i can give to the Customer.
However for pure Code/Bin-repos....i miss Bitkeeper :-(
We use mercurial and are happy with it. I hope we never move to git, but I can see us eventually moving to whatever is next.
[dead]
[dead]
It's missing what's sadly the only important difference:
Everything else is kind of irrelevant. Git is hard to use and awkward to master, but you need to do so anyone to work with everyone else.I wish it wasn't the case, but network effects are really important. Mercurial was a better DVCS launched around the same time as git but it lost out, not because "worse is better" but the network effects spreading out from the of the linux kernel itself.