This article begs the question - what might a sane/consistent UI on top of git look like?
I recently gave up for a number of reasons, though:
(1) It turned out to be hugely more complex than I had initially thought.
(2) There would have been the need to store additional meta-data in the Git repository. Combined with the need to intercept a lot of basic Git commands, that would have largely relegated Git to a transactional key/value store, which would have destroyed much of the purpose (interoperability with the Git eco system).
(3) Mercurial 3.2 introduced to bookmark management that emulated the behavior of Git branches better, which (in conjunction with hg-git) made it a viable frontend for Git, and it was in the end easier to fix my remaining issues with Mercurial via extensions than to fix my issues with Git via porcelain.
That said, I think the approach is still viable and in principle a good one, especially if you give up on some Bzr's features that yield relatively little for the amount of work involved (such as putting empty directories under version control).
[1] Bzr suffers primarily from abandonment issues, its basic design and UI (modulo some needed clean-up) is pretty good, especially the model it exposes to users.
The thing about DVCS is that it's allowed a whole lot of experimentation around different workflows, and two in particular have come to the forefront in particular: pull requests and git-flow. A porcelain designed around these particular workflows would be quite effective IMO.
Also, I think it would have some better, less jargonistic terminology. For example, something like TFS's "get-latest" as an alias for "git pull origin master" would be a lot clearer.
FWIW, I've only ever done git merges in a gui, and never had any difficulty with it.
It seems strange, but I really like having a console-based workflow with my VCS. I can leverage grep, shell aliases, and so on to customize my interface a fair deal, and the forced interaction helps keep me mindful of what I am doing.