Say what you want about Git, GitHub is awesome.
That's five to ten people, all writing code that interacts with each other's, all without any access to the SVN server. You can imagine the copy-pasta that went on. The amount of "oh fuck, I just rebuilt-all without Dave's changes". The amount of "Bags not merging this shit."
Then we'd get back to work after a weekend and have to merge all our independent branches. That could take a day or two on its own. Sometimes, sitting with five people's laptops in front of you and using the human brain's visual diff was more efficient than trying to do it properly.
---
Now, with git, we push and pull wherever the hell we like as needed. Everyone's laptop is equivalent to the server. When we get back, everyone merges their stuff into staging, all the cross-dependencies get magically resolved, we test it, and merge that into master. It takes about fifteen minutes.
(Actually, I don't work there any more, but the conclusion works better in the present tense.)
And Git handles branching and merging better than Subversion.
If you're not frequently using local branches, your stash, `git add --patch`, git bisect or git rebase then you're really missing out.
Everyone's git workflow is different which makes it even harder to get up to speed since you read about 10 ways to accomplish the same task.
You might not use ALL the features of git but once you master a subset of them you'll find that your workflow is unlike anything you could have done with Subversion.
Sure, you have to learn the (absurdly simple) model that git uses behind the scenes, but after you do that, who really cares about the standard CLI interface? That interface sucks in the same way a dashboard might suck on an all-terrian vehicle. Sure it looks like shit, all the knobs are in the wrong place and don't turn in consistent ways, and that analog clock seems really out of place in a car... but who really cares? It doesn't impede actual use.
Those "internal details of its implementation" are in fact what git actually is. "Learning git" without learning that stuff is not in fact learning git.
It's one thing to learn the internal implementation details when you are a power user who really cares about a particular tool and wants to master it: it's another thing to require everyone to gain low-level familiarity.
The whole point of a computer - indeed, the whole point of computing, if you look at it through a lambda-calculus lens - is to provide abstractions over lower-level details, thereby allowing human brains to spend less time worrying about those details and more time manipulating higher-level abstract concepts.
In failing to offer a high-level interface, git wastes human brainpower which could otherwise be spent solving actual problems.
You don't need to know what an AST or a symbol table or an intermediate representation are to use gcc; you don't need to understand static single-assignment form, linker relocation entries, or ELF segments. You can use the tool without any knowledge of its internal mechanisms. This is not true of Git, and that is why I hope it can be improved or replaced with something that has more respect for human brain power.
Nothing felt intuitive. The interface for vim might in fact be unintuitive and that might make learning it take longer.
But once you learn it, the un-intuitiveness is no longer a barrier.
I don't argue that learning git is difficult no matter what your background is. But that's the nature of a tool that's almost 100% un-opinionated on how you do something.
I don't disagree with your comment but I think that's inevitable for this type of tool.
How is it inevitable to have inconsistant flags for showing contextual help?
How is it in the nature of such a tool to have command names that are inconsistant (for example 'push' to not be the opposite of 'pull')?
I think in the end these things are relatively small oversights by Torvalds at the beginning, that have become rather difficult to fix now, after git has become such a standard tool - but it makes live really hard for every beginner. I mean imagine a GUI application where the help menu is sometimes accessed through F1, sometimes it's shift-F3. Imagine Edit->Copy would do something completely different than what people are used to form other similar programs. Even worse, in a GUI tool it's no big deal to fix those problems in version 2, but a CLI automatically becomes an API for other higher level tools such as GitHub and changing it would break it afterwards - so it's really important to get that interface right from the start.
For me the hurdle was not the API. That's what documentation is for. It makes learning it inefficient to always check the docs but that's about all.
It does less than a local SVN server, there is no server.
Git is peer-to-peer, which is a huge advantage. Because it is decentralized you can access your whole repo and its history while off-line. That and easy branching are the main selling points of Git though over time you discover more and more ways in which Git is subtly superior.
If I could start over again on my main repo I'd do it in Git but I already have all my files dating back a long time in an svn repository so the cost of transiting is huge. (it is a very large repository). But anything new is stored in Git. Maybe one day I'll work up the courage to do a proper transition.
I'm sure mercurial is nice, and given its users passion for it I might recommend it to people starting version control for the first time (I'm in academia, version control is surprisingly rare), BUT... I'd use the term "very sharp edges" and not "rough edges." My impression is that they're meant to be there.
I've tried to revisit GitHub many times, but I just don't get it - it's not as good as Mercurial or TFS, and I have no desire to 'follow' anyone or watch a project. I'm just too damn busy building apps and projects to pay any attention to anything I'm not actively working on.
I'm still waiting for the 'ah ha' moment on why so many people are talking up GitHub, but it hasn't happened yet.
Add to that a dizzying array of competing distros and hardware so slow it usually took hours to do a kernel compile. It was a frustrating time for computing in general and deciding to try using linux was a fairly daring venture certain to result in hours upon hours of frustration.
User groups had install parties so users would have a positive experience with Linux and not give up.