On Wed, 18 Nov 2009, George Dennie wrote: > > The Git model does not seem to go far enough conceptually, for some > unexplainable reason... Others already mentioned this, but the concept you missed is the git 'index', which is actually very central (it is actually the first part of git written, before even the object database) but is something that most people who get started with git can (and do) ignore. Now, admittedly, for casual use it's not always clear _why_ the index is so central, so the fact that you overlooked it is certainly easy to understand. Just take my word for it: to truly understand git, you do need to understand the index. You can ignore it for a long time, because one of the primary reasons for it existing is about performance. That happens to be a primary goal of git, of course, but some people always think it's "just performance". It's way more fundamental than that. So the way you can start getting used to the index is to think of it as a way to avoid having to do a full 'readdir()' on the whole tree to figure out what is in there, and avoiding having to read all the files to check that their contents still match. Of course, if that was _all_ the index did, it could be seen purely as a cache, and have no semantic visibility at all. And that's not the case: the index does have real semantic visibility. The first time you'll see it is when you decide to stage your changes in parts. The index is what allows you to _not_ always commit all your changes exactly because git keeps track of something more than _just_ your whole current working tree. A special case (but a really useful one) of the "staging your changes in parts" is when you do merges. Now, most people don't do merges like I do (what, average of 5 merges per day, day in and day out), so most people don't care quite as deeply as I do, but if you ever do a merge where 99% merged cleanly, and 1% did not (which is the common case for conflicts), you'll really understand why having a system that keeps track of the parts that merged cleanly is _critical_. So for merges, the index keeps track of what merged cleanly, and what didn't, and what the original state for the not-clean stuff was. And as somebody who probably does more merges than likely any other human in the history of the world, I can state with some authority that any source control model that doesn't have this is fundamentally broken. So the index is really _really_ important. Even if you can ignore it most of the time. And the index is why you don't have a model of "always just track the exact tree state". Linus -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html