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

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 30 Nov 2006, Carl Worth wrote:
> 
> If the "create file; git add; edit file; git commit" confusion isn't
> blisteringly obvious to the git maintainers then I think I have to
> give up here.
> 
> And this isn't just CVS-induced brain damage.

I'm sorry, but you are wrong.

It really _is_ CVS-induced brain damage, and I'm trying to teach you. You 
can give up, but that's really "refuse to see the damage that systems like 
RCS and CVS has done to the world"

The fundamental brain damage that CVS (and RCS, and SVN, and just about 
anything else) has had is thinking that "filenames" (and sometimes this is 
"fixed" to be "file ID's") are somehow special, and a totally separate 
thing from "file contents".

Really. It's a BUG. It's a deficiency in CVS and friends. And it's a 
deficiency that you have gotten so used to that you don't even see that 
it's simply obviously NOT TRUE.

You _cannot_ have a filename without the contents of that filename. That 
whole concept doesn't make sense, except in the twisted AND WRONG mental 
model of "files have identities even without content".

The whole point of git is that it is about "project state" and the history 
that binds those states together. People have kind of come to accept that, 
and a lot of people realize what it means, but I don't think you've really 
accepted what it means for something as simple as a "git add" command.

Again, totally ignore the index. Imagine that it doesn't exist. Imagine 
that you never actually learnt about it, and that none of the 
documentation ever mentions it, and just ask yourself:

	"What does 'adding a file' really mean?"

I mean _really_. It cannot be about the "filename", because a filename 
simply doesn't have any meaning alone. Remember what git is all about.

No, when you do a "git add", YOU DO NOT TALK ABOUT FILENAMES AT ALL.

	NOT EVEN CLOSE!

No. Git is, and has always been, all about tracking project content. The 
fact that CVS is crap, and thinks that "filenames" are special (and this 
causes major problems when you do renames), and the fact that SVN is crap, 
and things that "file identities" are special (and this causes major 
problems when you split a file or when two files join) is very much about 
THEIR F*CKING IDIOTIC FUNDAMENTAL BRAINDAMAGE!

So take five minutes to really think about that. Take an hour. Take a 
week. Ponder it.

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.

Sorry for shouting, but as long as you think "git add" adds a filename, 
you're just not getting it. And I think it's really sad that you don't 
even seem to understand that yes, this _is_ braindamage that has been 
forced upon you by decades of mental rape done by bad source control 
systems.

Please. File identities are _bad_ in the SVN kind of setting. The CVS kind 
of "filename == file identity" is even _worse_, but it's still exactly the 
same disease. It's the disease of thinking that metadata is somehow 
"different" from real data, and that "files" have identities that are 
somehow separate from the data they contain.

Face it, git is consistent, and if it acted the way you seem to expect it 
to act, it would actually be a BUG. Exactly because you cannot and MUST 
NOT think that "filename" is something that has meaning without "file 
content" (or "file type" and "file permissions" - they all go together).

And notice? NONE OF THIS HAS ANYTHING AT ALL TO DO WITH 'INDEX'!! The 
explanation above is not "this is how the index works". It's a much more 
fundamnetal issue of getting the right mental model, where the only thing 
that matters is contents.

So even without an index, "git add" should work the way it works, once you 
can just let go of the broken model that is CVS.

Please. Join me, Luke. The power of the git side is stronger. I am your 
father.