On Sun, 6 May 2007, Matthieu Moy wrote: > > Well, git's index still tells more than "the content FOOBAR exists, > somewhere". It also "contains", if not "points to", the file name. Indeed. Git's index is basically very much defined as - sufficient to contain the total "content" of the tree (and this includes all metadata: the filename, the mode, and the file contents are all *parts* of the "content", and they are all meaningless on their own!) - additional "stat" information to allow the obvious and trivial (but hugely important!) filesystem comparison optimizations. So you really should see it as *being* the content. The content is not the "file name" or the "file content" as separate parts. You really cannot separate the two. Filenames on their own make no sense (they have to have file content too), and file content on its own is similarly senseless (you have to know how to reach it). What I'm trying to say is that git fundmaentally doesn't _allow_ you to see a filename without its content. The whole notion is insane and not valid. It has no relevance for "reality". Also, you should realize that when you do git add X you are *not* adding the filename X. No, "X" is literally a "content path pattern", the same way it is when you do something like gitk X and it's worth always keeping in mind that in neither case is "X" necessarily a single file, but literally a pathname pattern that is used as a "filter" on all the possible patterns. (Of course, the filtering rules are different for "git add" and "gitk": in the "git add" example, you filter the working tree files, while in "gitk" you filter the files that git already knows about, so they are different, but in both cases you really should think of them as filters, not as "filenames", even though one _trivial_ filter is to give a filter that matches exactly one pathname). > The reason why I'm posting this is that I was wondering whether > "commit -a" not being the default was supposed to be a message like > "you shouln't use it too often". No, "git commit -a" is undoubtedly _convenient_. You can use it as often as you like. So as long as you see it as a convenience feature, and realize that "git commit" is actually a lot more powerful than just being able to always do the convenient, go on and use "git commit -a" all the time. When you hit a situation where you want to do something slightly subtler, you'll suddenly be really happy that you always had the convenience feature, but that git didn't make you think that it was how you _had_ to work. > > [...] it basically could be used ass a definition of CVS: [...] > ^^^ > Not sure this was intentional, but your spelling of "as" when used to > talk about CVS seems to reveal something about your state of mind ;-). Indeed ;) Freudian slip. But yes, I'm really down on CVS. The only thing I like less than CVS is SVN, and that's just because I think it's such a sad waste, not because it's actually _worse_ than CVS. (Ie I dislike SVN from a "it could have been so much better" perspective). 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