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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
