I think the OP makes a valid and argumented point.
E.g. "git push", similarly to "hg push" - without any extra arguments - do roughly the same thing, "push to the default location".
When was the last time you ever saw anything useful or insightful in comments about git vs. hg? There have been a few enlightening blog posts on the subject but discussion threads like this don't really provide anything of value.
What kind of comparison are you after?
To be more scientific, let's take "git push where" and "hg push where". Now count the number of ifs and buts that you have to keep in mind when using Git (am I pushing to the same remote? is the branch "set to integrate"? does the remote has this branch name?) versus plain "push everything to where you cloned from" in Mercurial.
My point is that Git has accumulated too much cruft and has introduced one too many concepts to be usable.
Your point is totally invalid, since git is self-evidently successful, and regarded by many people as usable.
The "cruft" you've pointed to consists of usable, useful features. So it would be useful to talk more about areas in which git could improve—even if that involves looking at features from Mercurial—rather than engaging in vague and abstract descriptions of "cruft".
With Git, it gained popularity not because it was terribly usable [1] or generally good (it was not even going to be an SCM [2]), but because it was imposed by Linus onto a pretty large number of developers - kernel hackers, not less - and then it spread from there.
[1]: http://marc.info/?l=git&m=111377572329534 [2]: http://marc.info/?l=linux-kernel&m=111288700902396
I'm also aware that nothing you said actually dealt with the fact that git is not unusable. In fact, it's objectively pretty good—if it weren't, we'd all still be using SVN.
What you seem to be saying is that you prefer the UX of Mercurial. Cool, that's fine - but I'd be keen for people to invest their time in improving the experience of using git, rather than bellyaching about perceived differences which aren't really all that big.
(As an aside, I don't really agree that there's a problem with git's usability. It's a complex tool, if you want it to be. But for day-to-day distributed SCM, you'll rarely have to care about most of that.)
Again, popularity has nothing to do with merit. It's a pure happenstance that Git was chosen over Mercurial for kernel development, and it all went from there.
The UX of Git cannot possibly be improved in the foreseeable future as it will be a _massive_ pile of breaking changes with people moaning all over the internet.
If you're looking to derail this post and do some trolling, then congratulations. You're off to a great start.
Git push by default pushes to where you cloned from. If you want to push to a different remote, you say so: "git push another-remote". If the remote doesn't have that branch, you create it, same as you would with bookmarks in mercurial.
git push == push all branches to origin hg push == push all changesets to origin
This (root) comment here is a good example: it isn't in any way related to the new developments in Git, repeats very basic comparison done many times already and fails to account for deeper differences and options (like the fact that you can easily configure git to make git push do exactly what you want).
It would be good for overall discussion quality if posts such as these were kept separate from the interesting stuff.
It's just you.
It's about time we'd put "hg vs. git" to the category of flamebait topics (similar to "emacs vs. vi" etc) that should be avoided. Every time there's a git topic, someone comes and derails the whole discussion with a not-quite-apt comparison with hg.
AFAIK, there are decent two-way conversion tools so you can use hg with a git repo and vice versa. There should be no need to argue because you can pick the one you like and use it.