| > and for anything more complicated you have to undertand how it works in order to use it, which is the greatest sin a piece of software can commit imho Actually, I think you are perfectly wrong about that "sin". You just hit upon the exact reason why Git is good. Git's point is that the data model is the tool. There is no abstraction (or at least very few), because it would only serve to camouflage what is important about it. It's just a data model and tools to manipulate it. The way to explain Git is to start with the database: blobs, commits, references, and so on. The neat thing is that the way Git implements version control -- that is, linear version control (there are exceptions, like Darcs) -- is how version control must necessarily work. In other words, if you understand Git, you understand how version control, and vice versa. Of course you can have a VCS that is a completely black box. But even a black box needs a sort of public data model that the user understands ("files", "versions", "branches"), and I think Git's transparent, open-engine-approach is better than any other approach so far. For one, it makes it really extensible. (I used to be a Darcs user, which requires that you become a quantum phycisist to understand its data model. I loved Darcs, but it meant that it broke, and it often did, it was almost impossible to fix the problem by hand.) Now, I absolutely admit that Git's UI is terrible. It's geared towards hard-core developers who work on things like the Linux kernel. There little middle ground between the easy and the hard, and the learning curve is steep. But this is the fault of the command-line tools, and my thesis applies regardless of the UI. Git has gotten better over the years. Just the fact that a newly created branch now has a default origin branch (so you don't have to set up the two .gitconfig keys you would need manually) is an amazing usability improvement that should have existed from the start. |