I got a lot of feedback on these videos (they are a year old now) and started on a new site that incorporates those suggestions at http://learn.github.com

Once I get all the same material covered, I'll probably start redirecting this site to the new one. I'm actually just finishing up a print book with Apress on Git that is CC-3.0 licensed, so I'll be putting a site with the contents of that book online soon too (then I'll have some free time to finish up the learn.github.com site).

I'd also recommend http://gitready.com/ which is a kick-ass Git focused blog with tutorials and the like. It's by HN user qrush.

These were a big part of how I learned git. Do check out his git internals book; the material in it is basically what's in the 'casts, structured along the lines of his RailsConf talk: http://gitcasts.com/posts/railsconf-git-talk

The approach he uses is very similar (a little bit more detailed) to this tutorial ("Understanding Git"): http://news.ycombinator.com/item?id=531517

Am I alone in not really liking screencasts?

I can't really go at my own pace, or skim, like I can with a web page. I can't cut and paste.

I can see why they appeal, TV vs. book etc. etc. Less perceived effort.

This site date representation is really not user friendly. At first I thought "Jul 13" is a schedule for near future, but after clicking it video showed up. Comments are marked "48 weeks ago", so after some calculations I could finally confirm it's from last year.

Great suggestion. One of my pet peeves is sites that don't show the year in the date of the post, never mind the ones that don't show a date at all. The date is extremely relevant when it comes to tech articles.

doesn't it say something about git's usability that there are so many help guides, tutorials and screencasts just to try to show its basic functionality?

it's a revision control system for pete's sake. it should track revisions in your code and let you get back to work.

I think the fact that a lot of people feel driven to take their time to write about a tool is much more indicative that it is an incredibly helpful tool, not that it is difficult to use. If you used some tool and it was really hard and barely got the job done, would you feel passionate enough to write a post or tutorial on it? Does horrible usability drive passionate proselytizing? No.

The fact is that proper version control is a hard problem. Tracking your work quickly and simply without forcing you to conform to a workflow prescribed by the VCS tool itself is a non-trivial problem (unless of course your work is itself trivial). Git solves this problem elegantly and efficiently and the amount of information popping up recently are from users who are thrilled that a tool finally exists that does not limit how they do their work and who want to share that with others so they can work better too.

I am driven to do all the Git related stuff that I do because I love the tool and it is so much better than what I had ever used before, not because it's frustrating to me or I feel it's hard to use.

"I think the fact that a lot of people feel driven to take their time to write about a tool is much more indicative that it is an incredibly helpful tool, not that it is difficult to use. If you used some tool and it was really hard and barely got the job done, would you feel passionate enough to write a post or tutorial on it? Does horrible usability drive passionate proselytizing? No."

But there are things about git that are non-obvious, and tricky if you've been accustomed to cvs, svn, or even hg.

It's sort of like learning OOP after years of BASIC. Once you get going, you may wonder what was so hard about it, but getting a proper mindset can be difficult.

The same goes for Emacs and Vim, we should all throw them out as they are not intuitive to use and that they need a learning curve.

Hasn't been updated in a year. I used to watch and subscribe, until they stopped coming out.