Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

On Thu, 30 Nov 2006, Linus Torvalds wrote:

What does it mean to "add" something to a project? It has _nothing_ to do 
with "filenames". Yeah, the filename obviously exists, but it's not 
something that exists on its own. You add the ONLY thing that git tracks. 

You add CONTENT.

When you do "git add file.c" you aren't adding a filename to the list of 
files that git knows about. Not even CLOSE. No. You are really adding 
_content_ to the project you are tracking. You haven't bound it to a 
commit yet, but it's there. It's there both conceptually, and very much in 
a real technical sense too (you've literally added the git object that 
that file describes to the object database - the "commit" and "tree" 
objects to tie it all together is just waiting to be added, but they 
really just expose it - the actual file object has already been created 
when you do "git add".)

So yes, you very much ARE talking about CVS braindamage. The reason why

	git add file.c
	echo New line >> file.c
	git commit

commits the _old_ content, is very much because git is ALL ABOUT THE 
CONTENT. It has _never_ been about filenames. And it _shouldn't_ be about 
filenames, because that would be BUGGY AND BROKEN.

Great.  But let me repeat my last question:

Would it make sense for "git add" to do the same as "git update-index" 
on already tracked files?  Given the explanation above this would make 
100% sense to me.

Even for newbies this might help them understand the power of the index 
with only one command. "You _add_ your changes together before you may 
commit."  That's simple to understand even for newbies.  And then 
they'll start using the power of the index even without realizing it.

But right now, doing "git add" on an already tracked file simply does 
nothing.  This is even worse than erroring out.