Linus Torvalds wrote:

The problem I have with "git commit" committing everything dirty by
default is that it encourages exactly the wrong kind of behaviour, ie the 
"commit it all in one go without thinking about it".

100% agreed

And "git status" really isn't that hard to type, and it will tell you 
exactly what you've already marked for commit, and what you have dirty in 
the tree but isn't marked for commit yet.

Having found about it recently, 'git status' is quite useful.

So I think the "git commit <file-list>" thing is very convenient, but it's
convenient exactly because it's concise yet still precise and doesn't 
encourage the "just commit whatever random dirty state I have right now" 
mentality.

And if you have more than a few files dirty in your tree, I really think
it's much better to do "git status" and think about it a bit and select
the files you do want to commit than it is to just do "git commit" and let
it rip.

For me at least, providing a file list is a pain, because I am so 
precise [read: obsessive] about keeping an otherwise clean working dir 
:)  Except in rare occasions, I know precisely that the changes in the 
working dir comprise 100% of what I plan to commit.

Locally I have scripted

      git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst
      git-update-cache `cat /tmp/lst`

because of this.

[again, clearly doesn't work with remove/add/mode change]

Now, I could well imagine adding an "--all" flag (and not even allow the 
shorthane version) to both git-update-cache and "git commit". So that you 
could say "commit all the dirty state", but you'd at least have to think 
about it before you did so.

That's pretty much what I suggested when I said

	git commit --figure-out-for-me-what-files-changed

:)

So I certainly agree there.

	Jeff