It's missing what's sadly the only important difference:
Git: Used by everyone else
Fossil: Not used by everyone else
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.
I never had a good experience with mercurial from memory. Docs and examples weren't as good (not that Git was hugely better, but network effects had more resources available). I remember the CLI commands being a small bit more intuitive but as someone new to DVCS at the time (as most people would have been) - it didn't really do anything special to help new users get a handle on the mental model for how it works. I remember Facebook publicly using / backing it, was surprised they didn't do more to promote it.
I used Mercurial before Git and found it way more intuitive. I don't have much to say about the documentation, I didn't have a problem with it, but that's not the reason.
It is not just because the CLI is more intuitive, though it plays a big part.
The main reason is that mercurial is more opinionated. On a default setup, only a few commands are available, and none of them let you change the history. If you want more, you have to add an extension. These are built-in, that's just a line in a configuration file, so that's not much of an obstacle, but you have to be deliberate. It gives a natural progression, and it better defines the project organization.
With git, you have everything and the kitchen sink, literally, as it uses the "plumbing" and "porcelain" metaphor. All flavors of merge, rebase and fast forward are available, there is a git-reset command that does a dozen of different things, there is stash, the staging area, etc... The first month or two on git, I was a bit overwhelmed, none of that with Mercurial, and I already had the experience of Mercurial when I switched to git, so I was familiar with the concept of push/pull and DAGs.
Now, I tend to prefer git, though after many years, I still have trouble wrapping my head around the command line sometimes. But that's for the same reason it was so hard to me to get into it. It gives out a lot of freedom and possibilities. For example, I like the fact it is really decentralized, for example in one project the customer had a completely separate central repository we couldn't access, and they couldn't access ours, for security reasons. We worked by exchanging bundle files. At some point we also took advantage of the fact that it is possible to have more than one root commit. Also, almost all mistakes are fixable and it is hard to really lose anything (including secrets, so beware!).
For a video game analogy, Mercurial introduces you to new game mechanics as you progress, while Git makes you start in the middle of the map with all the skills unlocked.
Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.
> From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
Facebook moved from subversion to git around 2008. Some of their teams then switched to mercurial around 2014 (I could be wrong by a couple years here or there). By 2014, git was already the main tool everyone was using —- no amount of backing by a single company would have tilted the scales.
I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.
My favorite thing about jj is that it takes the mental model of Git that makes sense (it's a DAG of commits, with references to some commits for metadata like tags & branch names) and just uses that. Instead of the actual full data model of Git which has several unnecessary complications like the index & mandatory branch names. It's much easier to reason about.
Tried jj several weeks ago... and absolutely love it.
A life non-goal for me is becoming proficient in a version control system and Git, insofar as I've been able to tell, demands that you become proficient in an uncomfortably large subset of its features in order to get through any workload, even in the simplest realistic cases.
jj did take some getting use to, but after a couple days it was all sorted and actions which terrified me in Git felt natural and safe using jj. The kind of things that required me to go back to the git documentation (or stackoverflow, or some blog posts) to be sure I was holding it right... in jj it comes easily and naturally.
That jj offers sufficient power under a simple interface to get through the day ... while being compatible with those that use Git... make it a no-brainer for me.
Gt was not successful because of network effects, but more monkey see monkey do imitation that people are prone to. Whatever is used for big projects must be the best, right?
I have recently returned to Fossil for personal stuff. IMO its better than git for one person projects and small teams. It was designed for a small team. What everyone else uses does not really matter for personal stuff. Nor does it matter if you are working with people willing to try something new. Nor does it matter to someone who can take a decision for a team.
Just rename root directory of project and double size of your repo
Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast
Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it.
Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.
As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
hg sees history as useful metadata, and therefore you shouldn't dress it up artificially.
git allows for folks to be Pinky's out with their commit history for warm an fuzzies.
If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.
Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.
Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.
So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.
Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?
Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.
Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
What's it matter if you have an extra commit to remove a file before merge? Perfectly valid, and doesn't hide anything.
Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"
If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.
I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history.
Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.
> Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
You're already deciding what information is important to the future when you decide at which points you commit.
Reductio ad absurdum: why not commit every keystroke, including back spaces? By not including every key stroke, you are hiding information from future people!
When using systems without history editing I simply make an order of magnitude fewer commits. With git I basically commit every few minutes and then edit later, and with not-git I simply don't commit until it's "ready". Either way all of those intermediate states aren't getting published or saved forever.
> Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo.
The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests".
When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.
I'm not sure what XP you're speaking from, I see modern day companies with all faults of orgs past because the tooling isn't saving anyone from the human tendencies.
If your problem with commit history is that folks have too many useless commits and you can't personally be bothered to focus on the meat of the PR, that'sa probablem with the commit author and PR reviewer. Not a fundamental need to prune logs.
I used Mercurial before switching to git. The positive difference from switching was how branches worked. I don’t know the technical details but branches on git felt “lighter” to use and maintain than with Mercurial.
There are plenty of situation in which all that matters is that the people actually building are happy with it and a tool that literally nobody else uses would be fine.
Indeed, for many engineering jobs (software and other) in some industries, it's entirely necessary to create new tools and use extremely specialiased. Good people will learn how to use (and build/improve them).
I'd possibly go as far as arguing that a sign of a good team is willingness to aggressively use the right tool for the job even if it is obscure or something they have to build themselves.
Sure, if you're hoping to get traction with an open source JavaScript library… git and github maybe be pre-requisites, but for projects of a certain sort "reach" and "adoption" by other developers are the most important metric. (Though, SQLite has done just fine with Fossil, so there's probably a degree of overstatement in the idea that it anything has to use git / be on Github.)
It matters until it doesn't. Git is the "lingua franca" but increasingly I see team members use only git integrations in the IDE, the web interface (Azure) or say, the Github desktop client.
Those users wouldn't mind switching to Fossil if the graphical interface is reasonably easy to discover and use.
Features don't matter as much as workflows matter. If they can swap to a Fossil integration for their IDE and their workflow doesn't change (or maybe only changes to click a different icon), it'll be much easier to switch and thus more people will be able to switch.
> 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.
Yeah. I was using Mercurial and, reluctanctly, had to switch to Git. Now don't get me wrong: I was forced to use both CVS and SVN in a thankfully very distant past so I love Git. But I do miss Mercurial. We switched exactly for the reason you mentioned: Git simply won the market.
Git won, Magit is awesome. Then all the Github and whatnots. It's Git, Git and Git.
And never bet against Linus, either: the world runs on Linux (and that's a good thing) and every tech company in the world uses Git. That's just how it is.
Mercurial was a tiny bit better but not that much better that it'd compensate for the entire ecosystem and people gravitating towards Git.
That’s fine. But it’s fun nonetheless to look at the alternatives, or non-alternatives for a lot of us who aren’t willing to do something else on the side that won’t hit the mainstream anytime soon.
IMO the Zeitgeist here leans a bit too much on saying that
- C is everywhere so [Zig/Rust/Nim/Odin] is out of the question
- Git is everywhere so [VCS] is out
- Only [Tech] can be used in enterprise [[what does this mean?]] so [new tech] is out
All of these can still be discussed. Because it’s not simply theoretical. People make their own Fossil repositories. People make things in [Rust/Zig/Nim/Odin]. And the point about some tech being everywhere has the same discussion points each time. So I’m a bit miffed to see this as the top comment.
> you need to [use Git] to work with everyone else
Programmers use different operating systems, editors, languages - is there any reason we all have to use the same source control tool? We weren’t doing so before Git came along.
You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols.
Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.
I remember when two engineers on our staff at $BIGCORP test-drove Git for a month and then gave a lunch-talk about their impressions for anyone who was curious about it. They were in favor of switching to it for local / team workflows. At the time, there would still be a translation layer back to our pre-Git company repo, but they advocated for the extra overhead for the gains in new workflow possibilities. You can guess what happened next.
Git had only been around for a handful of years at the time. If not for people slowly adopting it a little at a time, thus leading to the network effect, Git would not have become the dominant VCS of the day. So yeah, when things like this, JJ, etc come along, it's worth paying attention and keeping an open mind cause any one of them might be the "everything else is irrelevant," tool in fifteen years.
Git kinda requires you to read the git book. But I wouldn't call it "hard to use", once you know how it works most of the things it does are obvious (if occasionally badly named).
And you could probably get rid of like... 90% of things people complain about by just writing better frontend (and some people did that) to same backend
"Fossil has inbound and outbound Git conversion features, so if you start out using one DVCS and later decide you like the other better, you can easily move your version-controlled file content."
> 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.
People will call me crazy, but you can tell Claude Code what you need with Git on your local repo and it will spit out the terminal incantations, you can also... tell it to run them after you read them.
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.