It is possible that that is true, but I'd want a stronger backup. Making no negative comments about git at all sets off very strong alarm bells for me.
The author makes a point that git's more transparent approach makes certain things easy to implement and consistent. To reiterate his example, stashes are just objects in a place where they won't be found by default, but they still work with everything because there's no magic.
The second example shows that git trusts that the user knows best what to do. If you want to reset a branch to a certain commit, git allows you to do it, and because the data model is not hidden git can simply expose the needed operation (reset branch pointer) as is.
For the most part, git has neat porcelains for most operations nowadays, but the UI is sometimes a bit weird because it started off as nothing more than a set of tools to manipulate a DAG of content on disk. In my view this ended up becoming one of its strong points in comparison to other DVCS.
Had the post been called "An advantage of git over mercurial", I would have placed a much lower requirement.
If you give me some examples, I can probably roll them into a followup post later on.
That said, I really enjoyed the article. As a hardcore git user, I've occasionally skirted the edges of Mercurial (mostly just by poking at Golang) and always been confused at some of the stuff I saw. I knew Mercurial branches were more permanent than Git ones, but I never realized quite how permanent they were.
Git doesn't give you access to its functionality but instead gives access to its data model. Stashes are just references, commits are created or destroyed at will, notes are just objects that point at commits and are stored in a different set of references, etc.
Git itself is a bunch of scripts that wrap (lower-level) git tools. For example git's "native" `git rebase` command is a shell script:
https://github.com/git/git/blob/master/git-rebase.sh
You can create your own commands simply by putting a script called `git-whatever.sh` in your path, e.g. git svn-abandon:
https://github.com/nothingmuch/git-svn-abandon
I don't know hg's extensions, so perhaps I don't know what I'm missing, but I have no complaints about git's extensibility. It allows editing of its entire database and all branches (I've been able to convert SVN repo and re-create all merges, change authorship and dates of commits) and has hook scripts that can intercept and customize important actions in the workflow (I've been able to build non-trivial website deployment automation using git as a base).
The negative here is that A) git user has to know about all the tools, which takes a long time, and then solving the issue requires quite a bit of thought.
That's one of the problems about git is that as a result of the massive flexibility there doesn't seem to a "standard" way to do things, even basic things. Each org has to develop their own processes which is annoying and difficult for new people in the org.
I remember someone posting a recommended workflow for smaller projects, but I don't remember what it was called.
Commit Often, Perfect Later, Publish Once: Git Best Practices https://gist.github.com/1540906
just? Wtf is HEAD@{1} ?
That might be simple, but as usual, only if you know a lot about git.
As a casual git user this annoys me; Even when doing basic stuff I often have to read a long blog-post about how git works internally. I can't remember having this problem when I was a casual Mercurial user.