On Tue, 28 Nov 2006, Junio C Hamano wrote: > The above paragraph is not the important part of my message. > What was much more important is what immediately followed it, > which you did not quote: > > And at that point, I trust "git commit" to do the right thing -- > the damn thing I just checked with "git diff --cached" _is_ what > will be committed. Perhaps you'd be happier if the command to commit what "git diff --cached" shows were "git commit --cached" rather than "git commit -i"? (Or if they were both --index; how did we miss that last September?) It seems logical to me that "git commit" would commit the changes shown by "git diff" (in addition to changes in the index, of course, which are so obvious as to need no mention). I personally check with "git diff" and commit if everything there looks good; otherwise I tweak stuff until it does. And if there are a lot of changes, and all of those in some files look good, but those in other files need work, I can "git update-index" the ones I know I like so I don't have to go through them each time I'm checking on other stuff next time. > This is where "git commit" that does "-a" by default goes quite > against the underlying mental model of git. You staged what > should appear in the next commit in the index because you did > not want to worry about the local changes you still want to keep > in your working tree. That is not so clear to me. Maybe you're putting changes into the index to reduce the noise in "git diff", by updating everything that's unquestionable while you examine the other stuff. I think that everything in the index is clearly in the next commit, but it's obviously not true that everything in the next commit is in the index (because you might not be done updating things yet). > Doing the "screw the index" commit by default to these people is slap in > the face. You do not want to get your index suddenly screwed at the > final moment of making the commit, which happened to me when I did > "commit --amend" with the version with those two patches applied. I personally think that --amend should default to retaining the same tree, with options available for using the index or -a or paths. Using the index by default is just as wrong as -a; you're just more careful about it by experience. The index holds stuff to go in the *next* commit, but --amend generates a new version of the *previous* commit, so the logical basis for the new previous commit is the old previous commit's tree, leaving the index alone. -Daniel *This .sig left intentionally blank* - 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