Re: Updated git HOWTO for kernel hackers

From

JGJeff Garzik <jgarzik@pobox.com>

Date

Jun 23, 2005, 05:35 UTC

Message-ID

<42BA4A29.7030601@pobox.com>

In-Reply-To

<Pine.LNX.4.58.0506222146460.11175@ppc970.osdl.org>

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.

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