4 ms·

Wow. I'm surprised at the one-sided-ness of comments here at HN. I read the article and totally agreed. I've been trying to deal with all the complexity of w

Wow. I'm surprised at the one-sided-ness of comments here at HN. I read the article and totally agreed. I've been trying to deal with all the complexity of working copy/index/local repostory/remote repository/other remote repositories, merging changes back and forth, and umpteen other things, for a good few months now. It's genuinely Hard (TM). I have definitely done occasionally awesome things, like amending commits with small noticed typos before pushing, stashing is totally awesome, cheap branches are mostly convenient. But there's _so many_ layers, and nothing (that I've yet discovered) that lays it out in a manner that makes it easy to understand. I've a lot of past experience with Subversion. I used SVK for a while, so I could get local dev branches and commits without pushing to the central repository. But git continually confuses me. Plenty of it is un-learning other VCSs (no, to get rid of that mistaken change, I don't revert the file, I checkout the file. revert is a command but it does wholly other things.) Not to mention the many names for things. Local, staged, cached, indexed? Yowza.

steveklabnik 16y ago
Personally, I think that git is hard to learn if you try to think of it in terms of your previous VCS. As you say, you have a lot of svn experience, so maybe that's the issue. Really, at its core, git is incredibly simple. That's one of the reasons that it's hard. It's just a DAG of changesets, and every command lets you manipulate that graph, or give points on the graph names. Anyway, I'd echo several people's sentiments here: http://progit.org http://progit.org is a really good explanation, and also fairly short.