On Thu, 30 Nov 2006, Carl Worth wrote: > > The difference there is very subtle and really does prevent a > reasonable, "just ignore the index and you can use git comfortably". If you want to ignore the index, you'd always use "git commit -a". So what's your point? > But it is strange, and I cannot see how the first case is at all useful. The old argument by incredulity. The fact that you cannot see it doesnt' change the fact that I use it all the time. Usually not for the same file, but committing something that is different in the index and in the working tree is my normal behaviour - it's how any number of things work (like merging while you have dirty state, or applying patches while you have changes). So, let me condense the argument: - your argument is that cannot understand how anybody would ever want to use this. That's really what it all boils down to. That's your ONLY argument. You didn't actually answer any of me explaining _why_ it's how it works, and why it _has_ to be why it works. Your argument just boils down to "I can't believe it's useful to be consistent". My argument is: - the current behaviour is actually very powerful, and I've given examples of when I actually do use it (and whether you know it or not, they are also things you've probably done - the "pull from somebody else with dirty files" is actually exactly the same thing, you just never realized it just because it happened to be the same thing on two different files) - the "git add file ; change file ; git commit" behaviour is absolutely REQUIRED once you get the whole "git tracks content" logic. Doing anything but committing the old version (the one you added) would be illogical and wrong, because it's strictly against the whole POINT of tracking content. So. That's what it boils down to. Your personal incredulity against fundamental concepts and real usage. The reason I like UNIX is that it has "fundamental concepts". And surprise, surprise, a lot of the same issues are at play in "git" too. Pretty much _all_ the behaviour (apart from actual _naming_ issues) really come from fundamental concepts, and _not_ doing special cases. I guarantee you, in the end you're better off building a world-view on a coherent guiding logic, than on "personal incredulity" or "I can't believe that anybody would actually ever want to do that". As an X developer, don't you get tired of hearing people saying "I can't believe anybody would ever want to use a network transparent protocol and do graphics from another machine"? The non-X people (and every single "let's replace X with something more efficient" discussion) always tend to take that approach. Same thing. It really doesn't matter what you think is "normal". What matters a lot more in the end is that you keep a coherent set of concepts, so that once you really learn the concepts, it all makes sense. And in git, the over-arching concept for just about _anything_ is "git tracks contents, and filenames don't matter". The behaviour of "git add" and "git commit" is just a small detail in that whole picture. 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