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.
Comments
Conceptually, git is simple and elegant.
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.
At that point, why not just use Mercurial? What advantages does the git storage format give you?
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)
[0] https://bitbucket.org/durin42/hg-git/issue/1/http-cloning
> 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.
"Git for your boss" would be great, because I am terrified every time my boss uses git.