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

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 30, 2006, 15:58 UTC
Message-ID: <Pine.LNX.4.64.0611300749560.3513@woody.osdl.org>
In-Reply-To: <456EBBE7.8030404@op5.se>

On Thu, 30 Nov 2006, Andreas Ericsson wrote:

Show 11 quoted lines

> Linus Torvalds wrote:
> > 
> > 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.