The simplicity of git's data model is the root of the problem; that is the reason it is hard to learn and hard to use. It operates at a lower level of abstraction than the level we are thinking at when we are actually developing code. Git is less of a version-control system and more of a library one could use to build one, but in absence of any canonical high-level git wrapper, we all end up implementing and running one in our heads. This is a waste of brain-power.
Um, no. I think the git data model is perfectly good for real life version control. It turns out you don't need a higher level of abstraction. The problem IMO is that the UI doesn't map cleanly onto the natural operations on the data model. It might just be my ignorance, but the fact that I can have an operation in my head in terms of the git data model (which is fairly automatic) but not automatically know how to translate it into a git command is problematic.
To say I disagree is a massive understatement. I've seen teams try to use wrappers and just mess everything up because they don't understand what's actually going on in the underlying system.
Git has the concepts it has because they're all important. It shows them all to unfiltered because to do so is vital.
Can you give some concrete examples? It sounds to me like you haven't used git in an awfully long time, and are repeating things that were only true in the git 1.4 and early git 1.5 days.
I use git daily and have done so for years, but it's true that it has been a long time since I've actually tried to understand it. I gave up on the documentation, which seemed to be written in such a way that it would only make sense if you already knew what it was trying to tell you, and just memorized the handful of recipes I need to get my work done. It's not pretty; it's one of the bad tools, which I occasionally have to wrestle with, and not one of the good tools, which fit onto my brain like extensions of my body.
That's interesting. My experience was the opposite: I've also been using git since 2008, and I find it to be the most intuitive, friction-free VCS that I've ever used.
I think the difference is that I didn't start with the official documentation. I watched a video of an introductory talk given by a local Linux kernel developer. The talk started with an explanation of the underlying data model, and then showed how each command manipulates the underlying data structure and how that's useful for version control.
The talk is a bit long and a bit dry, but to date, it's the best introduction to git that I've ever seen. I highly recommend it:
