I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git.

What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

Branching in Mercurial is as good as or better than in git, but it takes a few minutes of additional reading until the full flexibility of Mercurial's model actually reveals itself. Revisions can be safely ignored in favor of commit hashes. I haven't used revision numbers in hg for at least a decade now. And hg has a stash implementation that is on par with every other VCS that I've used so far.

TortoiseHG is a very good client that covers all common Mercurial operations and then some. It's on par with a couple of commercial git clients that I've used. On the server side, there's e.g. heptapod as a GitLab fork that has a deep Mercurial implementation.

When I used it a decade ago, virtually everything in mercurial was slightly better-designed, more user-friendly, and more polished. Much shorter learning curve.

It had a much better GUI in 2009 (THG) and I think today the GUIs for git aren't really better - probably worse.

“Far better tooling” means that you don’t need to do git help reset and try to remember each of the nonsensical choices, for example.

Gotcha - most people here probably use git for more complex stuff - I almost exclusively use the same 20 commands for my daily work and wrote a cheat sheet for them ages ago (I mostly memorised it by now). Occasionally i need to ask an LLM for some help but that’s maybe once every few months.

> What does “far better tooling” mean exactly

It means that git invented a bunch of new jargon and ideas that confuses people exposed to it for the first time, where hg's usage metaphor hews closer to the received wisdom of people coming from stuff like subversion and perforce.

It's true that git's ad hoc command line UI isn't exactly it's greatest strength. But given the complexity of the design space here that's a pretty weak argument IMHO. The two weeks it takes to get the basic git workflow into your muscle memory pale in comparison to the years it'll take you to be good at bisection and tree maintainership.

It's also sort of a wrong argument in the modern world. People new to git have extensive assistive technologies available. There is, after all, no HgHub out there.