Re: git index: how does it work?

From: Shaun Cutts <shaun@cuttshome.net>
Date: Aug 12, 2009, 11:52 UTC
Message-ID: <436D5ED1-2F0E-4227-AC4A-3A5FD16B2DCF@cuttshome.net>
In-Reply-To: <7v7hxi9m4k.fsf@alter.siamese.dyndns.org>

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:

Show 77 quoted lines

> Shaun Cutts <shaun@cuttshome.net> writes:
>
>> 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.
>