Re: git index: how does it work?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <shaun@xxxxxxxxxxxxx> 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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]