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

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 30 Nov 2006, Theodore Tso wrote:
>
> But then why is the default for "git commit" to commit the index, if
> the index is almost == HEAD?  And why is git-update-index given such
> prominence in the documentation?

The default is: commit everything that you ask for to be committed.

If you haven't marked anything to be committed (which you can do with "git 
add" too, or with simply being in the middle of a merge, or by having done 
something like "git pull -n" or similar that does everything _but_ 
commit), then git commit will say "nothing to do".

It has NOTHING to do with the index per se. 

I still don't understand why people are so hung up about the index.

So ignore the index entirely, and follow along with me:

	"git commit" with no parameters simply DOES NOT DO ANYTHING YOU 
	HAVEN'T ALREADY ASKED YOU TO DO.

It's that simple. It's that logical. Ignore the index. Ignore everything 
else. Just read that simple, straightforward, and logical sentence on its 
own. It all makes sense.

Then, the trivial follow-up is:

	If you want to commit _all_ dirty files, use "git commit -a". 
	Otherwise, name the files or subdirectories you want to commit 
	explicitly.

Again: THIS JUST MAKES SENSE.

Asking for "-a" to be the default behaviour is BAD.

For example, in "git commit --amend", it's _important_ that "-a" not be 
the default, because you may well want to just amend the commit _message_. 
No files updated AT ALL. You may have other state that is still dirty 
(because you didn't ask it to be committed last time), and they should NOT 
be committed, because the simple rule is:

	"git commit" with no parameters simply DOES NOT DO ANYTHING YOU 
	HAVEN'T ALREADY ASKED YOU TO DO.

Repeat the above sentence again. IT JUST MAKES SENSE.

So maybe the documentation shouldn't mention the "index" at all, because 
it apparently scares and confuses people. But the fact is, the 
documentation started out as _technical_ documentation, that explains the 
_technical_ side of git. We don't have lots of "end-user" docs. 

But the lack of such end-user documentation should not cause idiotic 
threads like this, where people blame "the index". 

Yeah, so the docs are too scary. But none of this has anything to do with 
"the index". It's all logical on its own, and the default behaviour to not 
commit anything you haven't asked to be committed is the right one.

Make "git commit" just say "You didn't say what you wanted to commit. 
Maybe you meant 'git commit -a'" if there's nothing to commit. How hard 
can that be? But don't change semantics now, and please DO NOT change them 
to something _worse_ than what we have now (and automatically adding the 
"-a" only in _certain_ circumstances is definitely much worse imnsho)