On Wed, 22 Jun 2005, Adam Kropelin wrote:

I know I shouldn't invoke this particular acronym, but I rather like 
CVS's approach.

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

Also, CVS really doesn't have much choice, since CVS doesn't _have_ the 
notion of marking files for commits. In contrast, in git the index file 
really does end up beign a good way to say which files are ready to be 
committed.

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.

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.

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.

		Linus