Is the Git staging area just an index?

Question

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 index is more commonly known as the "staging area".

But if we modify the file foo.txt that is already part of the repo, and use git add foo.txt to stage it, and modify the file again, now the file is both "staged" and "modified" (as seen in git status), and if we commit, the "staged" version will go into the commit. The second edit won't go in.

So how can the "staging area" keep track of what the first edit was if it is just an index -- a list of files?

Pacifically

Answer 1

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.

Vinasse

This is pretty old question, but I still can't find the answer on is the staging area and index same? Because, everywhere I look it up, it shows, that git add actually adds file to the index, as well as git add puts the file(s) into staging area (area, where files get before committing). So, are the "index" and "staging area" concepts same or not? I think it's very important to be clear about terminology and the difference (if there is any) between these two terms. – Silvestro

Answer 2

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.

Bois

I liked your example with the out basket but you didn't mention how that related to staging at all – Ecumenicity

@EthanDavis the Staging are is, for the most part, identical to the Index. The difference is more one of perspective. The Staging area is a conceptual view for the user, while Index is more of a Git developer viewpoint (where they keep the lists of what is in the 'staging area'). Git has a lot of things named by (and for) the devs, which then get misunderstood by users ;-) – Bois

Answer 3

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.

Podvin

Answer 4

It's an index but to a list of modification trees, not files directly. See the different type of objects git handle.

Piatt

The first three words are right. The rest is wrong. – Podvin

Answer 5

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.

Weirdie

You're wrong about this. The index is an index. Calling it a staging area was part of the effort to explain to people who'd never encountered such a thing in a vcs before why you'd want such a thing in a vcs. – Podvin

Answer 6

the index is not actually a list of files that we see in the project. it's a list of blobs that will be present in the snapshot we're going to commit next.

consider a blob to be a file that contains the compressed content of a specific file, for example foo.txt at a specific moment. (more on that here)

when you add a file to staging area using for example git add foo.txt a new blob for that file is generated which contains the content of the file at the moment you added it to the staging area. we can see that by using git ls-file -s. we'll see something like this:

100644 9cdf71db89dabc03936d7e685d812272e8976274 0 foo.txt

so if we make any changes, we still have the previous content stored in a blob and the index file still has a reference to that (i.e. its SHA1 hash 9cdf71db89...).

(the actual blob is stored in .git/9c/df71db89... and to see its content we can use ‍git cat-file -p 9cdf71db89da)

Farrel