Last year, I started work on an attempt to basically create a Bzr-like [1] porcelain. I still think this would be the way to go for a serious attempt to provide a consistent, but reasonably powerful UI for Git (especially given that Bzr and Git actually have a fair amount of commonalities under the hood).
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.
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.