Goswin von Brederlow wrote: > Other RCS use an index of files they track. Git uses an index of patch > chunks to commit. Same name, totaly different concept. What you say is correct in terms of how some people use the tools. But underneath, the index is a cache that tracks the content of all files. To make the index not match the work tree is to deliberately let it go stale (or to cheat and poison it, or whatever). I am making an assumption about other version control systems and it is probably wrong for some. Here is the logic: suppose I 1. Make some changes to files. 2. Invoke “vcs commit” 3. Pull out the power plug. What happens? If the version control system is sane, then either the entire commit takes place or nothing visible happens; because otherwise, the result is that I screwed everyone over. The easiest way to implement this is to make “vcs commit” two steps: 1. Prepare the proposed changes in a staging area. 2. Atomically commit them. Traditionally, “atomically” means “with a lock, on the remote server which has a steady power supply”. In particular, the index I am talking about tends to be on the _remote_ machine. Making it local leads to a lot of improvements. Early in the design of git’s user interface, it took some time to figure out how visible to make the index [1]. Personally I am happier with the modern approach of letting people dirty the index if they want to, but if you believe that is wrong, maybe you would like to look at the Cogito scripts for inspiration [2]. There are still many lessons to learn from them, I suspect. More importantly, it might be fun or interesting. Hopefully that is a little clearer. Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/780/focus=918 As you can see, cogito, the most widely used front-end in early history, did hide the index from the user. [2] http://git.or.cz/cogito/ (warning: they have not been maintained for a while) -- 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