Let me be clear
Over the past few years git has become wildly popular, which is great. Git is bringing DVCS goodness to the masses and that is a good thing. It is frustrating when much of the documentation for things like MVC web frameworks and Configuration Management systems assume that you'll be using git for version control as if it's the only logical option, but hey what can you do? In short I like git and tend to recommend it in professional situations when there isn't already a DVCS in place. In part, this is because of the community and ease with which one can get support.
My dad can beat up your dad
Zed Shaw did a great post some time ago about why he uses fossil. The essence of my position is pretty similar to his: It's about yak shaving (you should really read his post). Here's a quick run down of why I use fossil over git/github and hell, we'll throw in mercurial too.
- Single (small) executable file - Fossil is self-contained and compact. It's one file that handles everything unlike git which requires perl or mercurial which requires python. Fossil is so compact that it's been run on embedded systems, routers and phones.
- Batteries included - All by itself the fossil executable includes multi-user access control, a web server, a wiki, a blog/news feed, and a ticketing system/issue tracker. With git and mercurial you need to cobble together a bunch of other pieces of software to get any where near that much functionality.
- I control it - Anyone remember SourceForge? Github is great as long as your needs line up with theirs. Personally I don't put much stock in the idea that our concerns are congruent or compatible. I may be wrong. My fossil setup is run on my servers and I don't have to worry about the interests of a company in which I have no say.
- One file repos - With git and mercurial your 'repo' is a working directory containing a .git or .hg subdirectory with all of the sauce to make your repository an actual repository. With fossil you have a single SQLite3 database as your repository. This means that moving the repo around is as simple as copying one file. There's no more permission hell from multiple people committing locally and no need to repack.
- Multiple working directories - With Fossil you can have multiple peer checkouts from one repository at a time, which is very useful for myriad workflows. Imagine a configuration management system where you have testing, staging, and prod as branches and live directories. You can make updates to one or more working directories and push them without needing to either commit, check-in, switch branches, and then check-out or clone the repository twice which would present a merging/push/pull headache and take up space unnecessarily as with git and mercurial each clone has the full history of changes.
- Simple sync'ing over http(s) - This was a clincher for me. Git sync'ing over http is not elegant and requires much hoop jumping. Having SSH as the only reasonable mechanism for push/pull operations is just not working for me when I have to be on different networks with different policies about what services are or are not accessible. Often SSH is blocked while HTTPS rarely is. Even if forced to use a proxy fossil still works.
Maybe the above list doesn't hold any weight for you. That's ok. I'm not trying to tell you to not use your preferred tool for version control. I like fossil because it does the above with minimal effort on my part. Your needs may differ.
