Re: [FAQ?] Rationale for git's way to manage the index

On Sun, 6 May 2007, Matthieu Moy wrote:

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).

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.

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