Messages in this thread | | | Date | Wed, 22 Jun 2005 21:54:23 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Updated git HOWTO for kernel hackers |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |