can someone explain succinctly what they like about fossil over git? I found a few overall articles but a nice HN comment would also help if anyone is game. Are there certain types of projects where it just works better for you than git?
On top of the command-line user interface being much easier for most people (it’s not as orthogonal as Mercurial, but it’s much more consistent than Git’s), the ability to have bug tracking, code, and wiki in a single executable, where all assets (not just code) synchronize, makes kickstarting a new project with full hosting environment ridiculously simple.
How good are the bug tracker and wiki? My immediate reaction to this idea is to throw up in my mouth a little bit because I remember the TFS experience, everything was integrated but all the individual components were worst-in-class.
I can see the value for small and/or personal projects, but beyond that is there a good reason to not use seperate best of breed tools?
From the experience of someone who used Fossil for small and large projects (solo and in teams) for 3-4 years, they aren't very good.
The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one.
(I've seen people talk about workarounds, like writing cron jobs to monitor the RSS feed of a fossil repo and send off an email, and, frankly speaking that is not a very good solution. It's going to be a little fragile and it's not administerable by non-scripting-savvy folks.)
The wiki is also kinda wonky. Doing file attachments is weird, or was when I used it, the markup is non-standard (not mediawiki, not markdown), etc.
The worst part is, while I can learn to work around the various oddities that basically all spring from Fossil being the product of folks who don't use a lot of other tools (and consequently don't see what other tools have essentially standardized on), I can't reasonably expect my less-savvy team members to be as dedicated in learning this one tool, because, ultimately, for what?
How is fossil so much better than github or whatever? It didn't get us any farther, except now people have to learn some quirky new interface stuff. Day-to-day, zero benefit.
I think your critique of the usability of the tools is completely spot-on, but I wanted to note one thing you reminded me about here:
> The bug tracker can be heavily customized, and get ready to do so, but it still has irritating limitations that are, when I checked a few years ago, WONTFIX limitations. Sending emails on bug tracker activity is one.
The modern Fossil versions can be compiled with real Tcl for scripting, rather than just TH1, which makes solving this problem, and a pile of other automation-centric issues, very trivial--at least if you don't mind coding in Tcl. (NB, you only need to do this on the central server, for obvious reasons; everyone else can just use the off-the-shelf binaries.)
The rest of your comment completely stands, and is why I don't actually use Fossil.
Fossil’s bug tracker and wiki mostly evolved out of cvstrac, which also inspired Trac that you are likely familiar with.
It is similar to trac, more bare bones but about as functional, and infinitely faster and more responsive. It is also completely distributed; do you have a copy of your issues and discussions for the day github eats them?
Serious question: can you point me to the unorthogonal features of git? I personally never had an issue with it but maybe I only need some hints to see them.
> can someone explain succinctly what they like about fossil over git?
Think of basic github functionality packed in a stand alone, self-hosting binary with a really good CLI and integrated help, ticketing, users and web interface to manage most of that, do diffs, create zip/tar archives, patches, change repo properties. It can also work in a client/server fashion, somewhat similar to subversion, but it's a distributed VCS instead so every client and server retains a full copy of the repository. The repository is replicated instead of sharded, so if you clone it you've got all the branches, all the tickets, everything but the unversioned content, the users, the settings and the css themes. Thus, your backups are equal to the number of clients in the event that you somehow manage to damage the repo on the server (which is just a repo where everyone syncs). It's also very easy to pick up without much wading through the manuals, something I always find myself doing when using git. Every command has a `fossil help <command>`. Most of the functionality is also usable through the web interface. It just works seamlessly on multiple platforms.
> Are there certain types of projects where it just works better for you than git?
Smaller projects, as in not Linux kernel sized. Projects where you don't throw a myriad of binaries in the VCS; there's the `unversioned` command for that. Projects where you have a relatively stable team, not a lot of random outside collaborators like on most succesful opensource projects on github. Projects where you'd want to self host or maybe keep private. I also use it on servers for configuration versioning.
It gets really slow if you dump large files in it. That was the drop that made me switch to git. Otherwise I used fossil for my own little tinkering for years.
* Single file repository with proper transactional semantics (it's an SQLite DB) rather than a "pile of files" implementation. I can trivially and safely copy the repository, send it as a mail to a new collaborator, etc.
* Fossil is a single executable. Unlike Git or Mercurial, that makes installation trivial.
* The whole system is remarkably clean, simple, and lacking in cruft. This also makes it easy to explain and get people started.
* Fossil has a well thought-out system for tags and named branches; they are persistent, but can be renamed. This is different from Git, where history tends to be largely a soup of anonymous objects, and Mercurial, where it is impossible to rename branches.
* It comes with a built-in wiki and distributed ticketing system. If you want to self-host rather than rely on GitHub/Bitbucket, that's already a very useful feature.
* `fossil undo` is very useful, even though it supports only one level of undo.
* The ability to store and share unversioned files is often very convenient.
Things I don't like about Fossil:
* The console interface is sometimes too simplistic for some commands (`fossil timeline` is one of the biggest offenders); it errs in the opposite direction from Git and relies on a GUI too much for basic operation (though I'd still prefer it over Git, but not necessarily other VCSes). That said, you can script it fairly adequately either with the JSON interface or even through direct SQL queries if you don't mind investing the time.
* The workflow for external contributions for contributors without commit access is more cumbersome than necessary; in principle, `fossil bundle` serves that need, but it lacks some features (you can't bundle non-commit artifacts, for example).
* Commit messages all get squished into a single line of output. You could argue that wiki pages or technotes are the proper way to document more complex information (so you don't have to sift through commit messages), but it's difficult to relate them to a specific commit and they aren't supported by `fossil bundle`, as mentioned above. There's some unfinished work on attaching remarks to commits [1], but this work seems dormant.
* Scalability is even more of a problem than with other distributed version control systems if you're dealing with really big repositories (not that those other systems necessarily cover themselves in glory, either), though the situation has improved in recent years.
