The book Pro Git says that the staging area is just a list, or index, that says which files will be committed when a git commit
is done, and now the name inde
The index
is like an out basket of completed work. At any point you can add
a (part) completed file to that out basket and it will replace the previous copy with your current copy, so that when you finally decide to commit
it will use the contents of that out basket (the current index
) to create the commit.
In addition your earlier add
will have create a blob object within the repo that can be found if required via the various logs. After a while (30 days+) it will disappear with gc
.
Index is a view of your working directory that is ready for commit. It can be seen as a pre-commit state and is not as simple as a "list of files". When you do git add
, the file (with the change) is added to the index and the newer changes will not be see until you add them too.
So how can the "staging area" keep track of what the first edit was if it is just an index -- a list?
An index is a list of names and pointers to content. In books, it's page numbers. In the Git index, it's object ID's in the repository's object database.
That's what the Git index is, a pathname-indexed list of content pointers.
git add
for some pathname is basically
sha=`git hash-object -w path/to/it`
git update-index --cacheinfo 100644,$sha,path/to/it
except git add
checks for executable files and uses 100755
for those, and does recursive adds and checks your .gitignore
and whatever else seems like it's usually most convenient. It's a convenience command for adding content to the object db and updating the index.
It's an index but to a list of modification trees, not files directly. See the different type of objects git handle.
The staging area is not just a list, nor index, which says which files will be committed when a git commit is done.
If it were that, i.e. a simple list, git add
could never work as advertised.
Rather, git add
has to save the contents of the file at the time that the add command is given. So it snapshots files, and then puts these snapshots into the staging area, (aka 'the index', which IMHO is really a rather poor choice for a name).
So yes, in fact, the book's statement is misleading and confusing. But this isn't too surprising. Much of the git documentation is confusing and poorly thought out.
Go ahead and mark me down. I'm sure I'm right about this.