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:
> 
> The difference there is very subtle and really does prevent a
> reasonable, "just ignore the index and you can use git comfortably".

If you want to ignore the index, you'd always use "git commit -a".

So what's your point?

> But it is strange, and I cannot see how the first case is at all useful.

The old argument by incredulity. The fact that you cannot see it doesnt' 
change the fact that I use it all the time. Usually not for the same file, 
but committing something that is different in the index and in the working 
tree is my normal behaviour - it's how any number of things work (like 
merging while you have dirty state, or applying patches while you have 
changes).

So, let me condense the argument:

 - your argument is that cannot understand how anybody would ever want to 
   use this.

That's really what it all boils down to. That's your ONLY argument. You 
didn't actually answer any of me explaining _why_ it's how it works, and 
why it _has_ to be why it works. Your argument just boils down to "I can't 
believe it's useful to be consistent".

My argument is:

 - the current behaviour is actually very powerful, and I've given 
   examples of when I actually do use it (and whether you know it or not, 
   they are also things you've probably done - the "pull from somebody 
   else with dirty files" is actually exactly the same thing, you just 
   never realized it just because it happened to be the same thing on two 
   different files)

 - the "git add file ; change file ; git commit" behaviour is absolutely 
   REQUIRED once you get the whole "git tracks content" logic. Doing 
   anything but committing the old version (the one you added) would be 
   illogical and wrong, because it's strictly against the whole POINT of 
   tracking content.

So. That's what it boils down to. Your personal incredulity against 
fundamental concepts and real usage.

The reason I like UNIX is that it has "fundamental concepts". And 
surprise, surprise, a lot of the same issues are at play in "git" too. 
Pretty much _all_ the behaviour (apart from actual _naming_ issues) really 
come from fundamental concepts, and _not_ doing special cases.

I guarantee you, in the end you're better off building a world-view on a 
coherent guiding logic, than on "personal incredulity" or "I can't believe 
that anybody would actually ever want to do that".

As an X developer, don't you get tired of hearing people saying "I can't 
believe anybody would ever want to use a network transparent protocol and 
do graphics from another machine"? The non-X people (and every single 
"let's replace X with something more efficient" discussion) always tend to 
take that approach. 

Same thing. It really doesn't matter what you think is "normal". What 
matters a lot more in the end is that you keep a coherent set of concepts, 
so that once you really learn the concepts, it all makes sense.

And in git, the over-arching concept for just about _anything_ is "git 
tracks contents, and filenames don't matter". The behaviour of "git add" 
and "git commit" is just a small detail in that whole picture.