Hi, On Wed, 19 Nov 2008, Miles Bader wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> I agree, but it would kinda handy to have an exception for files > >> explicitly named on the command line. > > > > Only if you do not have a clear picture of what the staging area is > > about, IMHO. > > That's such a vague statement, I've not sure how to take it. > > I use the staging area a lot, so I think I have a pretty clear idea of > what it's "about", but I also often use "commit FILE" or "commit -a" for > simple cases; even when splitting a change into multiple commits, it's > often more convenient to do "commit FILE..." instead of "add FILE; > commit". What I meant was this: the "commit <file>" paradigm is not what you should do most of the time. In order to work with the staging area efficiently, you should make staging and committing two separate steps. I regularly encounter people who never call "git diff --cached" before committing, and guess who introduces all kinds of debug statements and other cruft into their commits? Exactly. So my point is this: stage first, verify, then commit. That saves you a lot of embarrassment. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
