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

Linus Torvalds [off-list ref] writes:

On Sun, 6 May 2007, Matthieu Moy wrote:

quoted

But the fact that git actually remembers the _content_ of files in the
index, and that the default behavior for "commit" is to commit only
the content that is explicitely "git add"ed is something I've never
seen outside git.

Yeah. You'd better get used to it, because it's fundamental.

Thanks a lot for the detailed explanations.

Note that I'm not "complaining", but just not understanding something.

(I would actually complain about the documentation not being clear
enough, but I'll try to complain with a contribution instead ;-) I'll
add something to the FAQ on the wiki, but it's down right now).

 - You fundamentally cannot do it any other way.

   Not doing it the way git does it (point to the content) means that the 
   index-replacement has to point to something else, namely a "file ID". 

Well, git's index still tells more than "the content FOOBAR exists,
somewhere". It also "contains", if not "points to", the file name.

What's so hard with adding that "-a" to "git commit"? You don't even need 
it on the status line, the status is relevant and understandable (and 
actually tells you more) even without it.

Off course, I don't have strong argument against it. The biggest
annoyance is that my fingers are used to "commit -m message", and now
type "commit -a message", but ...

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

It seems it isn't. I'll just get used to "commit -a" (and probably
alias it), and discover the actual benefits of the index little by
little.

[...] 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 ;-).

Thanks,

-- 
Matthieu