In designing things for users, I think a lot about the difference between meaning and mechanism. In early computers, you were confronted with a lot of mechanism: switches to flip, magnetic media to treat worshipfully, mysterious incantations to type. But something like the iPad, the surface interactions are mainly about meaning.

When you say, "Git is a uni-directional acyclic graph for tracking patches," I believe you, and I believe that's how people like Linus think of it. But that's mostly mechanism.

For people who were soaking in large open source projects, I think that mechanism reflects their meaning pretty well. But for people putting stuff on the web, or building internal tools, it's very different. The base case is, "thing that is live now," and "thing that will be live soon". Patches? Don't need 'em.

For those people (which I think is the bulk of developers today), they are forced to deal with a lot of git's mechanism, to no real benefit. If git had been designed to be a popular VCS, I'd call that a design mistake. But I think it's hard to claim that; as you say, git makes sense in its original context.