I have never used Fossil, but I used to be a strong proponent of Mercurial. My advice is don't - Mercurial lost, git has won, and fighting against the current is just going to make your life harder.

The main advantage Mercurial has over git is a command line syntax that makes consistent sense. The operations you want to do are easy and as you try and do more complicated things, the new commands will be unsurprising and predictable. If you already know how to use git then this advantage is (mostly) irrelevant.

There are some other features that are interesting - Mercurial has a couple of different types of branches. Bookmarks are like git branches, whereas named branches are a completely different concept which can be useful. 'Phases' tracks whether commits have been shared, and prevents you rewriting (rebasing) them when appropriate.

If you do experiment, note that many 'power user' features are turned off by default. There is a robust extension system, and the default mercurial installation includes a load of standard ones. My config file includes the following to turn on some useful stuff ('record' is the most useful for a staging area like facility):

[extensions] pager = color = convert = fetch = graphlog = progress = record = rebase = purge =

I know Git inside and out, but I had to use Mercurial for a client a couple years ago. I found it to be the most baffling and nonsensical source control experience of my life. It might be a case of cross-contamination. Like you said, each SCM uses similar terms for different concepts, so my Git knowledge may have unfairly colored how I expected similar terms to work in Mercurial.

But stuff like: "hg log" gives you _every commit in the repo_?? When is that ever useful? How do I get only the commits that lead to the current state of the repo? Mercurial doesn't have branches; instead you're supposed to _copy the whole directory_[1] at the filesystem level?? Of course this is ridiculous, so they invented "bookmarks" which are actually Git branches. The extensions thing you mention is also a ridiculous chore. Just have sane defaults. I also found hg's output very dense and hard to understand and read, poorly suited for human consumption.

I dunno. I'm sure Mercurial is fine, many people use it every day, and likely my strong Git bias was affecting my ability to learn Mercurial. But I found it far easier to just clone into Git, use Git to do source control, and then export back to Mercurial when I'm ready to share my work.

[1] https://www.mercurial-scm.org/wiki/TutorialMerge

Mercurial does absolutely not require you copying at the fs level. You're not the first person to be caught out by that tutorial, which I think would serve us best by being deleted.

The 'original' branching method for Mercurial is called Named Branches. The big difference with Git is that every commit is labelled with what branch it is on. This has advantages - if you imagine looking at the train track of 'master' in git with it's divergence for a few commits and then merge, you can see that the 3 commits were on a branch called 'performance', whereas with git that history is completely lost. See: https://www.mercurial-scm.org/wiki/NamedBranches

As usage of git grew, the git branching model gained popularity and so the Mercurial bookmarks extension was created (https://www.mercurial-scm.org/wiki/Bookmarks).

It can be seen as a downside that there are two branching options that you have to choose between.

It's not just that tutorial, see also [1,2]. I think this is/was really an "official" way to do branching, and it seems utter madness to me :)

[1] Sadly the popular hginit.com seems dead, this was my first introduction to Mercurial. https://web.archive.org/web/20180722012242/http://hginit.com...

[2] https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...

Branching by cloning was copied from bitkeeper. It was also early git's only branching mechanism. If you listen to Linus's talk when he introduced git at Google, you'll hear him conflate "branch" with "clone" because that's what he was thinking of at the time.

https://www.youtube.com/watch?v=4XpnKHJAok8

I associate that particular madness with Bazaar rather than Mercurial. It stopped being standard practice a while ago, and those old tutorials should be updated or removed.

That is exactly the point. For git you need the ecosystem to cope with it's shortcomings and in addition some experts to help you out of the pickles this software gets you into.

I mainly use fossil for personal projects.

Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management. The setup is ridiculously easy and everyone always has everything in the repository.

In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

And fossil has a sane command-line interface so that everyone in the team is expert enough to work with it. No need for heroes that save the day from git fricking everything up.

> Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management.

That is not nice. That is way more things that might not match me, more attack surface, more irrelevant cruft I'll probably have to look up how to disable. Project management, wiki and issue tracking preferences are very personal and often don't map particularly well to specific repositories. And _blog_ and _mailing list_? Why, you're spending time on stuff most of your users will hate, not because it's bad, but because they either don't need it or would like it different.

> In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

Which is why Git is successful. That's by design, not accident. We want to, and sometimes _have to_, delete stuff.

>Whats nice about it is that it not only is a very capable VCS but also a complete project management tool with tickets/issues, wiki, blog, mailing list and user management.

That seems like feature creep.

Not at all. There's a lot of nice stuff that falls out of Fossil's integration of these features, things which you don't get when you lash them up from separate parts.

For example, if I have a check-in comment "Fixes [abcd1234]" I get an automatic link from that check-in comment to ticket abcd1234 from the web UI's timeline view. If I then close that ticket, the comment in the timeline view is rendered in strikethrough text, so I don't have to visit the ticket to see that it's closed.

Similarly, a built-in forum means the project's developers can discuss things with easy internal reference to wiki articles, tickets, checkins...

A recent feature added to Fossil is the ability to have a wiki article bound to a particular check-in or branch, so that whenever someone views that artifact in the web UI, they get a link to the ongoing discussion about it. This is useful when you have more to say about the check-in or branch than can reasonably fit into a comment box. This solves a common problem with experimental features, where you want to discuss it and evolve the idea before it's merged back into the parent branch.

Fossil's user management features are also highly helpful.

    http://fossil-scm.org/fossil/doc/trunk/www/caps/

With raw Git (no Github, GitLab, etc.) it's pretty much all-or-nothing, but with Fossil, you can say "this user can do these things, but not these other things." Thus you can set up a public project, giving anonymous users the ability to file tickets and read the forum but not make check-ins.

These features are as seductive as what Github, GitLab, BitBucket, etc. add to Git, but whereas those are all proprietary services with some of the roach hotel nature to them, with Fossil, you clone the repo and now you've got all of that locally, too. If the central repo goes down, you can stand your local clone up as a near-complete replacement for it.

It's not 100% because Fossil purposely doesn't clone a few things like the user table, for security reasons. You can build a new user table from the author names on the check-ins, though.

>In addition fossil never looses data, unlike git which can easily destroy branches that are not pushed, delete stuff while stashing or unstashing, delete stuff when rebasing and so on.

I have created a lot of feature branches that contain useless commits which I then later corrected with a simple git merge --squash. Preserving those commits sounds like a drag.

You're making bisects, cherry-picks, and backouts harder by squashing history like that.

We cover this and more in the Fossil project document "Rebase Considered Harmful": https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md

I hadn't heard of fossil yet, but I'll definitely look into it.

The simplest way to do that is to just use it for a local project. Say, you local ~/bin directory, containing your local scripts, or your editor's config files that you want sync'd everywhere, or a novel you're writing on the side.

If you're like me, you'll find yourself increasingly wonder, "Why would I put up with Git any time I'm not forced to by some outside concern?"