The porcelain, however, is incoherent and riddled with special cases. This makes it a hard sell to businesses and developers who struggle to understand that version control is a process, not a button.
So, articles like "Git for CS" are great and all, I guess, but what I'd really like to see is an article on "Git for junior Windows developers" or "Git for Your Boss" or "The case for git: delivering business value in IT" or "git vs TFS: how not to cripple your development team" or "git: because you don't just need to know how to program in language X, Y or Z".
> The porcelain, however, is incoherent and riddled with special cases.
Eyup.
Mercurial's UI sitting directly on top of Git's storage backend (replacing hg's own storage by git's) is an idea I've been wondering about for quite some time.
Git-using colleagues mainly, who may need to work on your machine for one reason or another (imagine git as the standard SCM and pair-programming, your using a different "porcelain" only works as long as your colleagues can keep using the standardized tool).
It'd also feel a bit less hack-ish than my current hg-git setup, and it would probably work correctly with http git repositories (I believe hg-git will support them once Dulwich 0.8.1 is released[0], but I've no idea if — and when — that'll happen, not to mention the issue will rise its ugly head again if git adds more protocols in the future)
> The porcelain, however, is incoherent and riddled with special cases.
Really? I'd ask you "Such as?" but I don't think any individual example is sufficient, since you say "riddled", so many examples would be required to illustrait your point. Individual commands may be conceptually overloaded, but overall I've found the interface to be quite consistent internally.
I've managed projects with both Mercurial and Git and have found that Git is consistently easy to use, where as Mercurial is very easy to use for the common case, and downright frustrating to use for advance cases.
The bottom line is that Git's UI assumes you know what you are doing. For the average corporate developer, that means that Mercurial is probably a better choice. Since Hg is optimized for the primary use cases. Git is about making simple things simple and complex things simple. Hg is about making simple things easy and complex things possible.
> The bottom line is that Git's UI assumes you know what you are doing.
I don't agree. Git's UI assumes you know the implementation details and storage model of git.
If you understand what the porcelain does in terms of plumbing, everything "makes sense" (for low values of "making" and "sense"), but in and of itself, without knowledge of the underlying implementation model, Git's porcelain makes absolutely no sense.
Just read a little of the above link. Personally I think http://progit.org/ does a better job of a conceptual walk-through while at the same time giving you exactly what you need to get started tracking your projects. It also explains the different types of suggested collaboration strategies in a way that you think "ah that makes sense".
Personal thanks to Scott Chacon if he's reading =)
My favourite one is The Git Parable. It walks you through the steps you'd take to make you're own DCVS. Once you understand this, reading the man pages makes a lot more sense.
This is a great post that gets mentioned from time to time and covers the underlying theory well. I'd supplement it with Chapter 9 of the Pro Git book: http://progit.org/book/ch9-0.html , which focuses more on the actual implementation and shows how to create commits from scratch using Git's content-addressable primitives.
The porcelain, however, is incoherent and riddled with special cases. This makes it a hard sell to businesses and developers who struggle to understand that version control is a process, not a button.
So, articles like "Git for CS" are great and all, I guess, but what I'd really like to see is an article on "Git for junior Windows developers" or "Git for Your Boss" or "The case for git: delivering business value in IT" or "git vs TFS: how not to cripple your development team" or "git: because you don't just need to know how to program in language X, Y or Z".