To be fair, the MQ and rebase extensions are shipped with mercurial, just not enabled by default. They share the same bug tracker as the main project and in my experience are just as well documented and tested as other bits of Mercurial.
It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default.
Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.
I'm aware that they're shipped but disabled by default. I think there's something of mental blind-spot, however, because they're discouraged or treated as something only experts should use: I've never seen anything like the level of obscure error messages or cumbersome UI in any part of Mercurial which is enabled by default. I think it deserves more respect as a valid working style.
I would disagree with the statement regarding history rewriting and non-expert users, to note two exceptions: Git's amend commits are extremely easy to explain and rebase is not that much harder for common cases. These same users are going to have issues with merges and rely on good tool support nearly as much in that situation, too.
What I think would be welcome in Git is the very nice phased commit feature you mentioned. That's a great example of where the concern should have been directed towards the UI rather than the operation.
Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one.
Shelf isn't shipped with mercurial and it's really really painful without it: you make some changes to some wrong branch and now you need either shelf or major pain with rebase.
If non-expert users don't understand enough to do rebase, they're screwed: they better go cry in a corner since you can't solve any non-trivial scenarios without rebase and you're going to run into those all the time.
Not that I like git, but still. And since Eclipse plugin for SVN merges much better than both git and hg, I often wonder why do we bother at all :(
Your comments highly suggest that you are not by any means a knowledgable mercurial user. You don't have to "assemble" mercurial from parts to do history rewriting. Enabling the relevant extensions amounts to adding a single line to a config file. I usually copy the same config file around when installing mercurial anew so that I can cut out even that step.
Shelf isn't that necessary because of mq, which is bundled by default. It is very feasible to use mq as a simple shelf substitute, much easier than using it for its more complex usage scenarios. Also, for your use case, it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again, so you don't even need shelf or mq to do that if you haven't checked anything in.
Ugh. Thinking about going back to that workflow makes me physically ill.
Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm working on source code, git allowing me to do stable, local "bookmarks", keep multiple local branches (and local history) active simultaneously, and keep all my content tracked... Git has its flaws and warts but don't seriously suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's bringing a knife to a gunfight.
I suggest that if you can understand a linked list, you can understand git. And if you're a programmer that can't understand a linked list... well... print out your "cheat sheet", here's a copy of Tortoise, and commit your code to a branch before it gets approved for main-line.
I only suggested the diff/patch workflow for the simple case where you realized after making edits that you were in the wrong branch. It might even be possible to just update to the correct branch and have mercurial automatically try to remerge your changes, though I haven't tried to know for certain. I think you're taking my suggestion way out of context, though I could be misunderstanding you.
Mercurial has remote-trackable bookmarks now (something I felt they needed for a long time). I agree Mercurial's branch tracking in general isn't nearly as good as git's, local branches being the biggest example. There is a local branch extension for mercurial (http://mercurial.selenic.com/wiki/LocalbranchExtension), but having used it a long time ago I'm not sure I'm the biggest fan.
However, I firmly believe that mercurial is in the same league as git and both are more than good enough to get the job done, and each have their relative strengths and weaknesses. I also believe that the outspoken part of the git community tends to be overzealous and blind to git's faults and Mercurial's strengths.
Well, if I need to turn on a few extensions and download obscure python scripts just to get the minimum viable experience, I consider the "Lego" badge mine.
"it's pretty easy to hg diff your change to a file, switch branches, and then use the GNU patch command to apply your changes on top again"
It feels like mercurial developers wanted to inflict pain on me, and makes me want to hurt them in return.
See, it's three steps. It's four actually, because you also want to delete the diff file.
You know how many steps did it take in SVN? Zero.
When you switched branch, it just preserved all your changes and applied those back. You didn't have to do anything.
Maybe it didn't work when there was a conflict - once per 100 switches. But mercurial won't let you do that - that's 100 per 100 switches.
Why should I have to assemble my DVCS from parts before I would be able to use it? If I wanted Lego I would have got one.
Because sometimes simplicity is a good thing? I'm not a Mercurial user, but there are plenty of times when decoupling features is a good thing- look at Mozilla Communicator Suite (or whatever it was called) vs. Firefox.
For the record, I use git every day and I'm yet to need rebase. No, my projects aren't all that complex, nor do they have a huge number of branches. But I suspect that is the case for a lot of other people, too.
Not sure he's accurate when referring to Github users, but I think he's probably not far off for git users in general. I mean, most git users aren't the people hanging around here. I don't see a reason to expect that more than "the simplest thing that could possibly work" to be commonplace.
When I use git (I tend to use hg more because it's more friendly for Windows projects, where I often find myself), I generally work on master for personal projects where I'm the only committer. It's easier for that use case. Branches are primarily valuable, IMO, when you have multiple people bashing on it at once.
It's also been my experience that non-expert users don't understand the repository DAG model well enough to perform history rewriting reliably and without error, which I think is one reason these features are disabled by default.
Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits which make local non-shared commits mutable whereas commits which have already been shared are immutable. This new feature is a first step to safer history editing operations becoming more mainstream mercurial commands.