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:
> >
> > So you can do
> >
> > 	echo a > file-a
> > 	echo b > file-b
> > 	git add file-a file-b
> >
> > 	git commit file-a
> 
> But, wait a second. What if I do my typo fix to file-a in between that
> "git add" and the "git commit". Why should "git commit" insist so
> vehemently on committing the _old_ state of file-a while "git commit
> file-a" so happily commits the _new_ state?

Because that's what "git commit filename" means.

It means "commit the changes to this file".

> I'm really not seeing conceptual consistency to what "commit <files>"
> does compared to "commit".

Exactly what the command says. "git commit" says "commit everything I've 
told you to commit". While "git commit filename" says "commit the changes 
that I've made to this file".

Yes, they are two totally different cases, but nobody sane can claim that 
it is strange. Exactly _because_ you explicitly list the filename, that 
also means that you want the file content AT THAT TIME. If you don't list 
the filename, you obviously must be talking about committing something you 
did earlier.