http://www.joelonsoftware.com/items/2010/03/17.html
He also happened to write a tutorial for mercurial that explains the same concepts. The tutorial is linked to at the very end of the article.
It's a pretty good tutorial. But to me the mere fact that there are so many posts on How-to use a tool that is basic in a programmers arsenal, tells me that DVCS are a solution that lacks usability.
Edit: appear to have annoyed someone with that comment! But do go on - prove to me how high intelligence means that you don't need to do hard work, which is the proposition of the OP.
I don't think anyone's said that, or tried to say it (least of all me), at any point.
As for it not being a proposition on the human condition - I mistook what he was saying, but then after it was clarified I understand what was meant. It was unclear to me what was being said - interestingly enough, that is the entire argument being expressed for the reason why git is "hard work".
I put in effort where it's worth it. Version control doesn't even come close to hitting the top of that list.
On the other hand, I can tell you we have almost 10x more downloads than we have svn commits ;-)
To commit any changes, you type in:
git commit -a -m "thing that I changed"
git checkout -b newbranch
git commit -a -m "changes made on branch"
git checkout master
git merge newbranch
I tried Git but failed miserably with it. It could probably be attributed to the lack of quality tutorials at that time. I then thought, "Fuck it, let's try Mercurial" and stumbled upon hginit. That is one awesomely written tutorial. I use mercurial for my programming needs and find it totally intuitive to use.
I definitely found it easier than git, but that could be possibly chalked up to my bad introduction to git.
When I tried to learn Git (before Hg), I looked for tutorials but everything was all over the place and maybe they introduced too much too soon. Anyway, at the end of the day I find Hg good enough for my usage - init, commit, push, pull so far.
git does not work like that. It's like each command was cut in half and recombined differently, like interlaced video or something. It's all there, it's just harder to recognize.
The thing that people need to get through their head is that distributed version control is a whole different concept. There are some things it is great at. There are some things it sucks at. Centralized version control is great at some other things, and lousy at some other things too.
I am thinking for example that if you are going for a PA-DSS-certified application, git, particularly with the ability to rewrite history, is going to be a problem, but dvs generally will provide more problems in assuring the auditor that you can locate, trace, and take corrective action if someone introduces a security issue (perhaps intentionally) into your application. I don't see git really working in that environment.
On the other hand, if you have a lively project that everyone is experimenting with and you need to merge patches occasionally to create a stable release, yeah, it's much better.
For any given project, no matter how distributed the development, you will have a "blessed" repository, from which the official releases are made. The history of this "blessed" repository is made not rewritable, even if anyone can push new stuff to it. The config files and hooks can be made writable by only admins.
Or you use a maintainer model, where the "blessed" repository is not even pushable. A maintainer (or a group of them) chooses what he merges in.
I have concerns about git and used distributed version control years before git existed.