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

On Thu, 30 Nov 2006, Andreas Ericsson wrote:

Linus Torvalds wrote:

quoted

That said, I have to admit that I usually (a) don't do this very often (ie
this is not part of my daily routine) and (b) I tend to do "git reset"
fairly soon afterwards (or alternatively, just "git commit -a") to get back
to the situation where the index will match the current HEAD 100% again. So
the "index doesn't match HEAD" situation is always just a _temporary_ thing
for me.

A staging area is per definition meant to keep temporary things before they
are committed to their designated place so there's nothing odd about that.

Sure. It's just that some people seem to expect the index to be different 
from HEAD, and are afraid of being "confused" by it.

The fear seems to be about "git diff" getting different results from "git 
diff HEAD", and always having to _check_ the two.

So I wanted to make it clear that I never have that situation, because I 
never leave the index "dirty". I agree that there is nothing odd about it, 
but I think that people who don't actively use the index (or don't use git 
at all, and just worry about it) see it as a kind of separate entity with 
a life all its own.

I can see that if you think the index is likely to be out of kilter with 
HEAD, you'd always worry about "ok, so maybe the diff I get from 'git 
diff' isn't the _true_ diff, so now I have to do _both_ 'git diff' and 
'git diff HEAD' to make sure I know what's up".

I just wanted to clarify that that is never the case for me, and I doubt 
anybody else really does it either. For a very complicated merge, I could 
possibly see somebody having a dirty index for a day or two and taking a 
break with the index dirty, but

 (a) I've certainly never seen that myself (and it would have to be 
     something very messy indeed - I remember multi-day merges with CVS, 
     but that was because CVS is so bad at merging, not because the merges 
     per se would have been all that messy)

 (b) if you have a merge _that_ messy, I don't think you're likely to 
     forget about it, and rather than be confused about the difference 
     between 'git diff' and 'git diff HEAD', you'll be really really happy 
     that you have some way of seeing just the _remaining_ pieces, rather 
     than all the crud you already fixed up.

In other words, the fact that the index _normally_ matches the HEAD may be 
obvious, but it's also important - it's important to allay fears from 
non-index users about it being somehow scary and confusing. It's not.