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