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. Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html