[locknitpicker]

> I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling.

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.

[BeetleB]

> 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,

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).

[locknitpicker]

> 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).

This topic is not about stashing though. It's about UX and providing first-class support for a basic use flow. If git stash was an alias for creating a branch and committing local changes to it, the point still remains: the problem with Mercurial was how it went way out of their way to argue against supporting features that users actually wanted, and supporting it as a first class feature.

And to me that's why ultimately Mercurial was bound to be forgotten while the tool that met uses' needs attained the status of de-facto standard.

The same can be said about other major features such as support for large files.

To top things off, the way that git maintainers have been actively adapting to feedback from jujutsu's users is yet again proof of why git still remains the de facto standard.

[marcher]

It did have a kind of equivalent to stashes in the mq extension, but its interface was a bit esoteric compared to the rest of Hg, from what I remember.

[voidnap]

A lot of features that git had by default had to be enabled as plugins in mercurial.

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.

[locknitpicker]

> 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.

It goes a little deeper than that. Prospective Mercurial users who wanted a specific feature were first greeted with claims that they were in the wrong for even entertaining the idea they needed such a thing. The rationale was that Mercurial already did everything they could possibly wanted to do, and so by definition wanting to do something differently was proof the user was in the wrong.

But to stop hearing about how feature X or Y was needed, they could roll out their own extension and leave the project alone and not bother them with these silly things.

Shipping extensions by default is an absurdity, once you think about it. It's effectively a way to disable features by default and stop hearing about how the project needs to support a feature. And that's how Mercurial dealt with it's potential user base.

[amluto]

git rebase, for all its warts, was always better than mq. A failed mq-driven rewrite was destructive! (And it kind of had to be — if you were trying to edit revision 17, there was no number available for the original revision 17 because the schema didn’t allow two revisions numbered 17, so the original had be excised.)