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

[Linus Torvalds <torvalds@osdl.org>]

On Thu, 30 Nov 2006, Junio C Hamano wrote:
> 
> I sense that you are inviting me to argue for reverting the
> other "git commit" braindead which is spelled "--only" (and
> worse yet, it is the default).  I am very tempted.

I actually really like the current defaults for "git commit".

And I say that despite the fact that the defaults are _different_ from the 
original ones.

I like the fact that when you do "git commit filename", it really will 
commit _only_ that file, not the other files you added. It's logical.

So you can do

	echo a > file-a
	echo b > file-b
	git add file-a file-b

	git commit file-a

and it will only commit one of them. Now, admittedly, the status message 
that you get is slightly misleading (it says that "file-b" is untracked, 
which is not strictly true or at least somewhat confusing - it's untracked 
only within the context of that one commit), but this is all logically 
consistent.

And it's wonderful for noticing "Oh, sh*t, I forgot to commit that 
previous change, let's commit that other file first!". You can do things 
like this _despite_ the fact that you've added other files to the list of 
files to be committed.

The current semantics for "git commit" are really powerful, and really 
flexible. Yes, there are different "cases", but they all have their place:

 - "git commit" on its own:

    This is for things where you prepared things earlier: notably a merge, 
    for example. But it might be the "--amend" case too, where you simply 
    don't want to change any of the working tree, just the commit message.

   The fact that it has a nice fallback for the "nothing to commit" case 
   which basically just prints out the same thing as "git status" is just 
   gravy.

 - "git commit explicit/file anotherfile"

   This is great (and I use it) exactly for when you have random other 
   additions in your tree that are brewing, and you just want to commit a 
   particular fix that takes precedence. You may be in the middle of 
   something else, but you found a critical bug that needs to be fixed, 
   and while you _could_ do it on another branch, it's just a lot more 
   convenient to specify exactly what you want to commit.

 - "git commit -a"

   Sure, this is the common case, but just how painful is it to type those 
   extra few characters? And not defaulting to this is just sensible, 
   considering that "-a" really is not _that_ special, and the above two 
   cases simply aren't that unusual either. And it's just good to make 
   people have to _think_ about the fact that it commits everything that 
   have dirty.

At least for me, it turns out that the only mode I _never_ use personally 
is the "git commit -i" thing, which was actually the original behaviour, 
and which you'd think that I would encourage for that reason. But no. Of 
all the modes of "git commit", that's the one I think is the least 
important, and least interesting.

Of course, during a merge, you do need "-i" if you list files, but I think 
"-a" subsumes almost all cases (you _can_ use "-i file-list" or totally 
manually decide to have some extra edits you did that you don't want to 
commit together with the merge, but that's such a special case that I 
doubt anybody does it, so I don't think it's a big deal).

Anyway, we have "-i", and we don't force anybody to use it, so the fact 
that it's a bit odd and not that useful doesn't really matter. It 
certainly "fits" in the git commit family as another case, it's just not 
one of the important cases.