1

I have gone through Git object model and read other articles about git but couldn't understand clearly about Git staging area.

What does staging area actually do?

Does it create the blob object and tree object when we do git add and when we do git commit the commit object is linked to the parent commit and corresponding tree object which is already linked to it’s blob/tree object?

Or

Does it just stores the info in index file (that something is changed and when we do git add it says ready for commit) and when we do git commit all the objects creation and linking happen between commit, tree, blob objects?

Yug Singh
  • 3,112
  • 5
  • 27
  • 52
  • The very short version: the staging area *is* the index. There are three names for this thing: index, staging area, cache. This is perhaps a symptom of the fact that the first name for it ("index") was too generic. – torek Oct 04 '18 at 20:34
  • Possible duplicate of [What does the git staging area contain when the working directory is clean?](https://stackoverflow.com/questions/28351820/what-does-the-git-staging-area-contain-when-the-working-directory-is-clean) – phd Oct 04 '18 at 23:09
  • https://stackoverflow.com/search?q=%5Bgit%5D+what+is+staging+area – phd Oct 04 '18 at 23:09

1 Answers1

2

"Staging area" is convenience jargon for the most common and popular way to use the index. Your first option,

Does it create the blob object and tree object when we do git add and when we do git commit the commit object is linked to the parent commit and corresponding tree object which is already linked to it’s blob/tree object?

has it almost exactly right: git add puts what you added in the repo, and git commit ties the commit object to the parent commit and the corresponding tree object - - - but that corresponding tree object isn't in the repo yet, git commit builds the tree (that ties pathnames to content) by consulting the index, which is exactly what it says it is: an index, tying pathnames to content.

So, git checkout updates the index to point to the content it checked out at each checked-out path, and git add updates the index to point to the content it added for each added path.

So you can use this as a "staging area", git commit only cares what you've added, not what's in your worktree. This is why git checkout, git reset, git commit and git add all have --patch options: there's what you checked out, what you've added, and what's in your worktree. At any point it might be useful to see differences between any of those, or "take back" part of the changes you made, maybe because they belong in another commit or just need further work.

torek
  • 448,244
  • 59
  • 642
  • 775
jthill
  • 55,082
  • 5
  • 77
  • 137
  • 1
    To expand a bit: back in the early days of Git, when it was a collection of shell scripts around a few core commands, `git commit` was a shell script. It consists of: (1) obtain commit metadata; (2) use `git write-tree` to turn the index/staging-area into a top level `tree` object with subtrees; (3) use `git commit-tree` to combine metadata from part 1 with tree from part 2 and parent commit(s) from `HEAD` and `MERGE_HEAD` if present; (4) write new hash ID through`HEAD` into branch name. Modern `git commit` is a large C program that essentially still does these four steps. – torek Oct 04 '18 at 20:13