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

From: Linus Torvalds <torvalds@osdl.org>
Date: Dec 1, 2006, 00:21 UTC
Message-ID: <Pine.LNX.4.64.0611301618490.3513@woody.osdl.org>
In-Reply-To: <873b80tqvv.wl%cworth@cworth.org>

On Thu, 30 Nov 2006, Carl Worth wrote:

Show 13 quoted lines

> >
> > 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.