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

On Thu, 30 Nov 2006, Carl Worth wrote:

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

So what's your point?

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.