Subject: Re: A Basic Git Question About File Tracking [ANSWERED]

From: Jon Forrest <[email-masked]>
Date: Sat, 08 Oct 2011 19:42:28 -0700

On 10/8/2011 6:17 PM, Jakub Narebski wrote:

> You seem to be under [false] impression that git commit is about
> _changes_ / _changeset_.

This is correct. The Pro Git book says:

"You stage these modified files and then commit
all your staged changes"

Plus, even "git status" tells me

$ git status
# On branch master
# Changes to be committed:

But I see my error. Below is what I hope is a clear
explanation of what I didn't understand. It presumes
that the reader understands the git objects model.
Please let me know if anything is incorrect.
----------
When you "git add" a file two things happen:

1) The file is copied to the git objects tree.
This location where the file is copied depends
on the hash of the file's content.

2) An entry for the file is added to the git index.
This entry includes the same hash that was mentioned
in #1.

A tracked file has an entry in the git index file.
A copy of the file also exists in the objects tree.

When you run 'git status', git computes the hash of
every file in your working directory and looks
up each file in the index. If the file isn't found
then the file is shown as untracked.

When you do a commit, the hash values of everything
in the index are copied into a tree object. The hash
value of the tree object is then placed in a commit object.
No copies of tracked files in the working directory are
made at commit time. This is because the files were already
copied into the objects tree when 'git add' was run.
This is one reason why git commits are so fast.

-----

How's that?

Thanks to everyone for sticking with me on this.

Jon