You might very well be right. It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.
The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.
Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.
A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.
> It might be a fundamental flaw of Git that in order to use it, you have to understand its innards. Certainly, in order to use it effectively, and in order to avoid disaster, you need to now how it's storing data.
I've been using git for 5 years now, and I don't have a clear understanding of "its innards". I once read an overview of how it works under the hood and have a vague notion of what's going on.
What are the typical use case scenarios where you need to know implementation details to "avoid disaster"?
I can rebase/merge/push/pull/commit just fine while being ignorant of implementation.
I've never used it, but I've heard that Mercurial offers most of the power of Git, with much less of the pain, and an easier user interface. I'm willing to believe that this is true. I'll even believe (whether it's true or not) that Mercurial does provide a nice abstraction layer, one that allows you to ignore the underlying implementation.
The thing is, that doesn't matter at this point. Many people (including me) have gotten through the Git learning curve and now find it to be fantastically useful. I'm far more productive with Git than I was with SVN or CVS, and I'm not the only one to feel this way. As a result, you now have an ecosystem of tools, tutorials, books, etc. that all build on Git -- not to mention companies such as GitHub and GitLab that supply (relatively) easy-to-use tools and interfaces.
Also: A large part of Git's power stems from the fact that you're always thinking in terms of commits, and where those commits fit on your repository's graph. I'm not sure how you can abstract away from that, even if it's an interesting idea in theory.
A combination of critical mass (among open-source developers and a growing number of corporations), an ecosystem, and a powerful (if hard to understand) data model has made Git the standard nowadays. It's a crying shame that Git is so hard for so many people to get... but I've found that in my own work, the learning curve was more than worthwhile, and has made me more productive.