[spacemanaki]

> Maybe that's the problem, Git isn't something you can just pick up quickly

It is the problem, I think. Git isn't easy to use. It's a powerful tool designed by a very smart person (Linus) to manage a very complex project (the kernel). It's not a toy, and it's not designed for beginners. On top of that, the interface actually isn't that well designed, and is a pretty leaky abstraction layer that in many cases requires you to have some understanding of its internals [1]. But we're programmers, our work isn't always easy and the benefits of using Git or using any distributed version control system outweigh the alternatives (note that I'm not talking about Git vs Mercurial vs Darcs but rather about the previous generation of supposedly easier tools like SVN and CVS). So I really think it's worth struggling to master it and treat it like a first-class tool, that you're going to invest in because it's important, rather than try to find an easy way out.

I'm projecting on to you a little bit, and I apologize for that, but every time a Git tutorial hits the front page of HN, there are people expressing frustration or complaining that Git is too hard or too complex. Yeah, it's not perfect, but honestly, it's a damned good tool, and I think it's absolutely worth investing in. Most things worth learning are hard, and while that's not an excuse for poor tutorials (no comment on this one as I haven't tried it), I don't think programmers who take their profession seriously have much to excuse what seems like our almost constant desire for things to be easy.

Maybe the next generation of version control will be easier to use and have a more beautiful user interface, but Git is here now and there's an ecosystem around it supported by the network effects of its popularity, and I think that does end up outweighing the difficulty.

[1] That said, I think the inner core of its internals, ie representing revision history as a DAG of commits, is actually relatively simple, despite the poor interface. See this for what I think is one of the best intros to Git: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

[mixmastamyk]

Sounds like a false dilemma. Mercurial is here now, is powerful enough for a majority of users, is easy to use, and has an introductory book as well. After reading it and Spolsky's site, I picked it up in a few hours.

I think git is a good fit for people who find version control theory interesting, a endeavor in itself, or have complex workflows. For the rest of us, who simply need to work together (sometimes offline) with multiple synced backups, the complexity of git is too much.

Hg, for its flaws, keeps the simple things simple. I think the constant push from above to use git is a disservice, and I wonder if there will be a backlash at some point.

[spacemanaki]

I specifically wasn't comparing Git to Mercurial, and noted so in my comment, mostly because I don't have any real experience with it. It certainly might be easier to use than Git, I don't actually know. I also don't know how many people who bemoan Git's complexity and learning curve have tried Mercurial, or even used any version control, and how many are migrating from SVN or CVS.

[etanol]

I use them both and I can say that Mercurial is way easier to learn and use than Git. Obviously, Mercurial has less features but, is there currently any DVCS system that has more features than Git?

The funny thing about Mercurial and Git is that they build on top of the same core concepts:

http://mercurial.selenic.com/wiki/GitConcepts

[Domenic_S]

hg is leaps and bounds simpler than git. I came from a long svn background and picked up hg in about a day.

hg to git took several weeks, and I'm still learning.

I prefer git's handling of branches; hg never deletes a branch, just "closes" it, so you're left with a lot of mess if you do a great deal of branching. Other than that, I prefer hg.