Re: git index: how does it work?

Junio,

Your advice was very helpful.

Digging in, however, I find I still am in the dark on one point: how  
does the index track renamed files, and how to query it for  
information about them?

For instance, if I add a 5th step to the sequence:

5) git mv foo.c bar.c

Then I am told by "git status" that the file is renamed, but I can't  
seem to elict this info using "git ls-files". Under some circumstances  
even "git status" lists a new and deleted file after a rename.

Are renames being tracked by the index, and is there a more basic  
interface than "status" to query about them?

Thanks for any help,

--- Shaun

On Aug 5, 2009, at 8:00 PM, Junio C Hamano wrote:

Shaun Cutts [off-list ref] writes:

quoted

I am wondering if someone could explain and/or point me to an  
explanation of how
the git index works.

For instance, suppose I have a tracked file: "foo.c"

1) [I modify "foo.c"]
2) git add foo.c
3) [modify again]
4) git commit -m "blah blah"

Since I don't include the "-a" switch, the version I added on step  
2 is
committed. But how does the index keep track of these changes? Does  
the index
file actually contain the hunks of "foo.c" that have been modified?  
Or is there
a "temporary" blob created, which the index points to?

Step 2 hashes foo.c and creates a blob object and registers it to the
index.  Step 4 writes out the index as a tree and makes a commit out  
of
it.

Running this sequence might be instructive.

	1$ edit foo.c
       2$ git add foo.c
       2a$ git ls-files -s foo.c
	2b$ git diff foo.c
       2c$ git diff --cached foo.c
       3$ edit foo.c
       3a$ git ls-files -s foo.c
	3b$ git diff foo.c
       3c$ git diff --cached foo.c
       4$ git commit -m 'half-edit of foo.c'
       4a$ git ls-files -s foo.c
	4b$ git ls-tree HEAD foo.c
       4c$ git diff foo.c
       4d$ git diff --cached foo.c

- 2a shows the actual blob object that was created out of foo.c in  
step 2.

- 2b shows the difference between that blob (now in the index) and  
foo.c,
  which should be empty.

- 2c shows the difference between the HEAD commit and the index, which
  should show your edit in step 1.

- 3a shows the blob in the index; you haven't added, so it should show
  the same as 2a.

- 3b shows the difference between the index and foo.c, which should  
show
  the edit in step 3.

- 3c shows the difference between the HEAD commit and the index, which
  should show your edit in step 1.

- 4a shows the blob in the index; you haven't added, so it should show
  the same as 2a.

- 4b shows the blob in the committed tree and the blob object should  
be
  identical to 2a.

- 4c shows the difference between the index and foo.c, which should  
show
  the edit in step 3.

- 4d shows the difference between the HEAD commit and the index, which
  should now be empty.