Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> On Sun, 6 May 2007, Matthieu Moy wrote:
>>
>> 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
-
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