Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".

[Daniel Barkalow <barkalow@iabervon.org>]

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