Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> 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. > > So my point is this: stage first, verify, then commit. That saves you a > lot of embarrassment. You seem to be saying that you think that using staging area explicitly is necessary or somehow "more efficient" for making good commits, but on the face of it, that's simply not true. I'm extremely careful about committing clean changes, and do a lot of testing and pre-commit diffing. For complex changes which need to be split, the staging area is indeed a very useful tool, and I'm very glad git has it -- but it's hardly necessary for _all_ commits, and my experience is that in practice, many commits are indeed the simple sort which for which it's superfluous. My goal is not to "work with the staging area efficiently", it's to "make good/clean/tested commits, efficiently". Obviously this depends on work style, and subject matter. Sometimes one _needs_ to make biggish changes and split them for commiting, and some people like to use that work style even when it's not strictly necessary. Other times, changes are more obviously independent, and can be done, tested, and commited in a serial fashion without any splitting. Perhaps, given your work style or the type of work you, you use the staging area 99% of the time. For your case, maybe any git features which bypass the staging area are simply unneeded complexity. However, my own experience suggests that this is not universally true. I'd say I use the staging area for maybe 50% of commits. One of the nice thing about git is the way that it tries to cater to multiple work styles, so it seems wrong to reject a useful feature simply because you want to "encourage" people to use your preferred work style, when that work style is not obviously better. [Of course there can be other good reasons to reject this feature -- maybe it's too dangerous or mucks up the code.] > 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. [I'm not sure what the point of that was... for the record, no I'm not one of "those people". When I use the staging area, I use "git diff --cached"; when I don't use the staging area, I "git diff" instead...] -Miles -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. -- 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
