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

[Nicolas Pitre <nico@cam.org>]

On Tue, 28 Nov 2006, Junio C Hamano wrote:

> What you do _not_ have to worry about all the time is the local
> changes you do not want to go in your next commit but still want
> to keep in your working tree.

This argument has its converse.  What you should _not_ have to worry 
about all the time is whether your index really includes all the changes 
you want included in your next commit.

And whether wanting to leave local changes in the working directory 
without commiting them actually happen more often than wanting to commit 
every changes is arguable.

What should be pretty consensual though, is the fact that having 
experienced GIT users add an alias for "commit" actually becoming "comit 
-i" to preserve the current behavior is much easier than asking new GIT 
users do the same but with "commit -a".

So in that context I think having commit without arguments meaning 
commit -a is a pretty sensible default.  And I don't think it has any 
influence on the "learning about the index" issue.