Re: [FAQ?] Rationale for git's way to manage the index
- Date: Sun, 6 May 2007 12:54:10 -0700 (PDT)
- From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [FAQ?] Rationale for git's way to manage the index
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.
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
- 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
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
> > [...] 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 ;-).
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).
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