|
> Four, basic concepts. Why is this difficult? Because it's 3 more concepts than most people need. A simple remote repository, coupled with a working copy, is easy to understand (and also all that most people really need). You commit, you update. The only local divergences are the changes you haven't committed yet. In my experience, almost anyone can understand this semi-intuitively, and they only start getting confused when they hit merge conflicts. Git, however, introduces considerable more state that a user must understand. There is local working copy state. There is local repository state. There is remote repository state. There is other people's remote repository state. Those states can become in conflict with one another, which means that there are quite a few more places to hit conflicts, and lots of sharp edges in the tool (git) with which you'd resolve them. That's a lot of state, and it's state that most people don't actually need; it incurs a lot of mental overhead, even for people that understand how it works -- as evidenced by the fact that we're even having this conversation and two of you are debating how the index works. The fact that this is git's default operating mode means that git is a bit like using a thermonuclear weapon to cook your breakfast, when most of the time, a simple gas stove would do. The tool was built for Linux, where it was designed to handle competing, divergent organizations, all of whom maintain long-term ongoing forks, with existing political and technical disagreements, divergent code bases and divergent ideas of stability and support requirements, all of whom are independently and concurrently maintaining, sharing, and rejecting patch sets across the graph of organizations participating in Linux development. It's a huge, complicated, expensive, and messy development process, and it's nothing like what most organizations and projects need to support as their default mode of operation. The problem isn't the people, the problem is that the tool is too damn complicated. |