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

[Daniel Barkalow <barkalow@iabervon.org>]

On Mon, 7 May 2007, Guilhem Bonnefille wrote:

> 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*