3

I am very new in git.

I was just going through the concept of working directory and staging area.

i am not very much clear about the use of staging area.

What could be wrong, if staging area is not there and we could able to commit directly from working directory to local repo?

Apology, if my question is silly.

Thanks with Regards, JD

JD.
  • 71
  • 1
  • 6
  • 1
    Does this answer your question? [What is GIT Staging and Difference between Add To Index and Add To GIT Index?](https://stackoverflow.com/questions/24677225/what-is-git-staging-and-difference-between-add-to-index-and-add-to-git-index) – ilkerkaran Dec 04 '19 at 15:49
  • 1
    @ilkerkaran: that's not a duplicate, that's about a wording glitch in Eclipse. – torek Dec 04 '19 at 18:09

3 Answers3

5

Your question is not silly at all. It's one of the few underlying concepts founding the whole Git's edifice.

  • The working directory is the actual place you're working in, you can see your files when they're checked out, and that contains (among others things) the .git subdirectory. This forms your git repository, as well as your local copy of a remote one if you initially cloned it.
  • The index is the list of files that are actually followed by Git : it's formed by a single, flat, binary file containing size-fixed entries under the .git subdirectory, simply named index. This means that all files located in the working directory that are NOT explicitly followed by Git will always remain untouched.

You also need to know that Git is a snapshot-based SCM system : each time a file is modified, it's entirely recorded again. Git won't record the diff between version (at least, not at this stage). Each commit is therefore formed by a treeish file list referencing current versions of each of them.

That's where the index starts to be clever : when you add a file to the tracking list using git add, you're not simply adding its name and path to the index : Git also saves its current content in a object, thus starting to build the actual up-to-come commit's payload. When you then do git commit, git simply saves the content of this index as a new revision. This is what makes de facto this index a "staging area".

This has several consequences:

  • What's actually recorded in your new commit is actually the state of the file as it was when you did git add, not git commit ;
  • You can easily decide what you will actually commit: you're not forced to commit every tracked file that have been modified since the last commit ;
  • To determine what is the status of your repository, git simply needs to compare the states of the working directory, the index and the last commit (actually the one currently referenced by HEAD).

We can summarize this very last point by the following:

  • All working dir, index and last commit are referencing the same file content : the repository is up to date :
  • index and commit are the same, but working dir contains different file content : some modifications have been made and need to be added : "unstaged changes" ;
  • working dir and index are the same, but differ with last commit : some modifications have been made and have been marked for recording : "staged changes" ;
  • All three entities are different : some modifications have been changed, but you've modified your files again since last time you called git add (which remains perfectly legal) or you performed a partial addition based on patch hunks with git add -p to select only what's interesting in a file: both "staged changes" and "unstaged changes" are showing up in git status.

Finally, this gives a last but not least advantage : since modification detection is based on file content and not on its last modification time, you can easily cancel what you've done. When the file "accidently" goes back to what it was at the beginning, it will automatically disappear from git status's list.

Obsidian
  • 3,719
  • 8
  • 17
  • 30
4

Besides Obsidian's answer, which gets into what you can do with the index / staging area (two phrases for the same underlying Git thing). it is possible to build a version control system that does not have an index / staging-area in the first place.

Mercurial is such a system. In Mercurial, the work-tree is the proposed next commit. This does require a few extra tricks behind the scenes, but the system works fine, and newcomers to Mercurial have far less trouble with it, than newcomers to Git have with Git. It's pretty clear from this that the index / staging-area is a tough concept. It isn't strictly necessary—though it does enable various tricks—and a system that doesn't have it is easier to use.

But Git does have it, so if you're using Git, remember that Git keeps three copies1 of each file at all times: the frozen one in HEAD (the current commit), the staged one in the index, and the one you can see and edit in the work-tree. Use git add to copy from the work-tree into the index. Use git reset to copy from the frozen HEAD copy into the index. Use git restore, if you have Git 2.23 or later, to copy from the index into the work-tree.

(If your Git version is older than that, there's a git checkout mode that copies from index to work-tree. You can't copy into the HEAD copy as it's frozen! So the only options are: HEAD -> index, HEAD -> index -> work-tree, index -> work-tree, and work-tree -> index.)

Side note: the fancy git add -p and git reset -p do their work by extracting the index copy to a temporary file, comparing the temporary and work-tree copies, and making whatever changes you like—and then for git add -p, putting the updated temporary copy back into the index.

1Technically, all the Git-ified (compressed, frozen-format) copies are shared to every possible extent. What's in the index is the hash ID of a blob object. When you update the index from the work-tree copy, Git prepares a new-or-reused blob object, ready to be committed, and updates the index hash ID. Aside from the fact that there's no extra disk space used, this is generally not visible in doing ordinary work with Git. You can think of the index copy as a private copy, as long as you remember that git ls-files --stage and git update-index work with blob hashes in reality.

Note that even if you never commit some blob, Git keeps the blob around as long as it's still in the index ... except for a rather nasty bug with added work-trees, starting in Git 2.5 and fixed in Git 2.15. Meanwhile, using git add -p can create a lot of unused blob objects, which are eventually garbage-collected, but do use up some extra disk space until then.

torek
  • 448,244
  • 59
  • 642
  • 775
  • "But Git does have it, so if you're using Git, remember that Git keeps three copies of each file at all times: the frozen one in HEAD (the current commit), the staged one in the index, and the one you can see and edit in the work-tree." ... and here is my beef with the official docs conflating the nature of the index with how it's used. Even the pros fall into that trap and start drawing bad inferences. `git add` adds the content _to the repository_ and updates the index entry. Git does **not** keep three copies. Git keeps one copy, and an index entry pointing to it. The work tree is yours. – jthill Dec 04 '19 at 18:34
  • 1
    @jthill: yes, and sometimes I include this detail—but at the level most people use Git, that particular detail is irrelevant. It matters if and when you start using `git update-index` to replace the index copy, because now you need to know to use `git hash-object -w` first. – torek Dec 04 '19 at 19:54
3

You can use it to select what you want to commit -- these few changed lines from that file, that section from that file... that sort of thing would be hard to do without a staging area.

I like to add things to commit with the git add -p command, which goes through all your changed files and shows diffs section by section, where you can choose to stage each one separate of the others. Then you commit the result of that (and maybe run git add -p again to create another commit).

Philippe
  • 28,207
  • 6
  • 54
  • 78
RemcoGerlich
  • 30,470
  • 6
  • 61
  • 79