Mercurial at 20: Why It's Still Alive and Kicking

Twenty years is an eternity in software. Most tools from the early 2000s have either been rewritten beyond recognition or quietly retired. So when a FOSDEM 2026 talk titled "Mercurial, 20 years and counting: how are we still alive and kicking?" hit Hacker News, it caught my attention. The talk itself—and the 30-comment thread that followed—paints a fascinating picture of a version control system that lost the popularity contest but never truly died. Here's why Mercurial endures and what its story tells us about how we should think about our own tooling.

What's the story?

The linked video is a talk from FOSDEM 2026, the free and open source software developers' European meeting. The speaker, presumably a Mercurial contributor or enthusiast, walks through the project's history since its inception in 2005—nearly the same time as Git. The talk covers Mercurial's technical design (fast, clean, Python-based) and its niche communities that never left: some large companies, science and research labs, and die-hard hobbyists. It's not a plea for relevance; it's a celebration of steady, quiet survival.

The HN submission points to this talk with a title that already captures the sentiment: "how are we still alive and kicking?" The community response is a mix of nostalgia, respect, and honest reflections on why Mercurial didn't win but also didn't disappear.

Why Mercurial's HN thread resonated

The 30 comments are remarkably civil for a discussion about a tool that "lost." Many commenters share stories of using Mercurial professionally and personally, often with a tone of fondness rather than bitterness. One commenter, looking back on a pivotal decision, wrote:

Almost 20 years ago I helped our company choose between Git and Mercurial as the replacement for Subversion. Unfortunately, I helped them make the wrong choice, Mercurial. I say wrong because clearly Git won the war and I haven't used Mercurial since then. However, I still think I made the right choice from a technical perspective; I thought Mercurial was way more user-friendly while providing all the features and performance needed.

Another commenter, who used Mercurial at a large tech company, praised its simplicity: "At my previous big tech employer we used to have a mercurial layer on top of our legacy version control system. I loved it, much simpler and more clear than the typical workflows I have to deal with in git. I get it that with git you have more power, but do really most teams need that?"

The thread also touches on Facebook's use of Mercurial (which evolved into the Sapling UI) as a sign of its technical strength in large monorepos. And one user fondly remembered TortoiseHg, the Windows Explorer integration that many felt was superior to early TortoiseGit.

My take

Reading that thread, I felt a mix of familiarity and surprise. I've used both Git and Mercurial, and I've always believed Mercurial has the cleaner command set. But I've also never recommended it to a team because the ecosystem—GitHub, GitLab, CI integrations, and the sheer number of Git-literate developers—makes the choice a no-brainer for most. The HN comments confirm that technical superiority isn't enough. Network effects and market momentum are overwhelming.

Yet Mercurial survives precisely because it didn't try to fight that battle. Instead, it stayed focused on a core philosophy: a simple, consistent UI, excellent performance for large repos, and first-class support for Windows (which Git took years to get right). The FOSDEM talk likely highlights its use in niche areas like scientific computing, where reproducibility and a clean history are more important than the latest branching trick.

What I find most telling is that even those who "lost" the Git vs. Mercurial debate don't regret using it. That speaks volumes about the quality of the tool. It's a reminder that winning isn't everything—building something robust and staying true to your values can earn you loyalty that lasts decades.

What this means for builders

If you're a developer or engineering leader, the Mercurial story offers a few concrete lessons:

1. Ecosystem matters more than features. Git won because of GitHub, not because of its distributed model. Before choosing a tool, ask: "How easy is it to collaborate with others?" This applies to databases, frameworks, and even programming languages.

2. Simplicity is a feature. Mercurial's learning curve is famously gentler. Its command names (like hg commit vs git commit) are consistent; there's no index/staging area unless you want one. For small teams or solo projects, this can be a huge productivity win. Consider whether you really need the complexity Git offers.

3. Don't bet against longevity. Twenty years in, Mercurial is still maintained with quarterly releases and an active community. If you need version control for a long-lived project and you don't depend on modern Git workflows, Mercurial is perfectly viable.

Here's what setting up a basic Mercurial repo looks like:

hg init myproject
cd myproject

# Create a file, then track it:
hg add README.txt
hg commit -m "Initial commit"

Compare that to Git's equivalent—it's slightly simpler, no staging area by default. That's not a huge win, but it's real.

Should you care?

If you're an individual developer or a small team that values a clean, consistent interface and you don't need the latest bleeding-edge Git features, yes, you should consider Mercurial. It's especially strong if you work on Windows or need to handle very large repositories. But if you're building a product that requires broad collaboration, contributing to open source, or relying on services like GitHub Actions, stick with Git—the network effect is too strong to ignore. For everyone else, the most important takeaway is to question your own assumptions about what makes a tool "good." Mercurial didn't go away because it was bad; it stayed because it was good enough for the people who chose it.

More resources:

• HN discussion thread
• FOSDEM talk video (schedule page)
• Mercurial official site
• Wikipedia: Mercurial