Re: Updated git HOWTO for kernel hackers

[Jeff Garzik <jgarzik@pobox.com>]

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