Mercurial had bookmarks that were roughly the same as git branches.
The linear version numbers were quite useful to reason about and use in places that call for a "number" version number, and were useful relative to your "master" clone. That was not the primary way though, it had hashes like git too, that were the same from clone to clone.
Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.
You mean - when looking at the history?
Incidentally, once you get used to jujutsu, you realize that the question is meaningless. A merge is simply the child of two nodes. It's a symmetric operation between the two branches. The thing that makes it "complicated" in git and traditional VCS's is the insistence in assigning a name to the resulting merge (so if you're merging into main, you want to call the new node "main"). Since jujutsu doesn't automatically carry the name forward, you see the "reality" of merge being a symmetric operation (i.e. you don't merge a branch "into" another branch - you are simply merging two branches).
That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).
For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.
For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.
I’ve never understood the “everything must be rebased before every merge” desire.
"For a complicated long running feature branch" always simpler to repeatedly merge main into dev, easier conflicts solving etc
For simpler cases squash+rebase as default merge strategy trumps leaves a nice clean history.
And then, when you pull someone else’s in-progress work to inspect it, you end up with their branches showing up with their names and you ended up with revisions 13564-13592 belonging to someone else and showing up in your history graph even when you continue on your own work at revisions 13563 and 13593. I ended up using temporary clones and strip a lot.
git branches, in contrast, are delightfully unobtrusive.
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)
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.
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.
I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve.
That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.
I started with Mercurial, eventually got forced into git, and now use jujutsu.
Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.
And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.
Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.
(Same goes for index - no one misses it once they switch to jujutsu).
The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.
I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.