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.
> 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.
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.
[+] [-] politician|14 years ago|reply
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".
[+] [-] masklinn|14 years ago|reply
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.
[+] [-] snprbob86|14 years ago|reply
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.
[+] [-] civilian|14 years ago|reply
[+] [-] javert|14 years ago|reply
[1] http://www.eecs.harvard.edu/~cduan/technical/git/
[+] [-] apsurd|14 years ago|reply
Personal thanks to Scott Chacon if he's reading =)
[+] [-] dave1010uk|14 years ago|reply
http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...
[+] [-] keyist|14 years ago|reply
[+] [-] ximeng|14 years ago|reply
http://news.ycombinator.com/item?id=441670 - a link to this amongst other Git stuff from 3 years ago
[+] [-] kclittle|14 years ago|reply
[+] [-] dbbo|14 years ago|reply
[+] [-] RusAlexander|14 years ago|reply