Re: [FAQ?] Rationale for git's way to manage the index

From: Daniel Barkalow <barkalow@iabervon.org>
Date: May 7, 2007, 22:23 UTC
Message-ID: <Pine.LNX.4.64.0705071616310.18541@iabervon.org>
In-Reply-To: <8b65902a0705070440t40889af0p1fb8dbf7e2a072e4@mail.gmail.com>

On Mon, 7 May 2007, Guilhem Bonnefille wrote:

Show 5 quoted lines

> Hi,
> 
> As a newbie, I'm agree with Matthieu: the Git's index is surprising
> for people coming from CVS/SVN (mindless?) world. So a good
> documentation about this, even in tutorials, is really important.

I think that the confusing thing isn't really the index, but the fact that git, by default, will make commits where the content in the commit is different from the content in the working directory. (In fact, you can use git-hash-object --stdin and git-update-index --cacheinfo to do a commit which shares no content at all with any present or past state of the working directory!)

In other version control systems, you have to use some option or argument to make that kind of non-matching commit (and you're generally limited in how your commits can fail to match the working directory). I think the confusion is that git requires an option to say that you want the commit to match the working directory, as opposed to creating a non-matching commit, which is generally the more advanced and more unusual case.

I think this is why people mostly get to understand the index by way of using it to resolve a conflicted merge: in that case, you have to make the index match the working directory before committing, and the index tracks your progress in reaching this state, which is the intuitive use of the index in normal situations.

	-Daniel
*This .sig left intentionally blank*