1

I have much confusion about staging area. firstly, Git Gud: The Working Tree, Staging Area, and Local Repo tell me the staging area will be empty after git commit,on this way, git commit maybe move files to local branch rather than copy.

But it seemed this cant explain this practice:git reset --soft HEAD~ modifies staged snapshot?. git reset --soft HEAD^ after git commit, and then git status, it seemed there exist difference between staging area and HEAD^, and the difference is the files which has been committed after HEAD^. On this way, it seemed that staging area is not empty after git commit, or rather how to explain the difference between current HEAD and staging area if staging area is empty?

And another question is that the command

  git diff --cached

which used to compare the difference between staging area and HEAD. And What does 'stage' mean in git? tell me staging area only store the file change. For example we git clone a project which has three files:a.txt b.txt c.txt,and we modified c.txt and git add it. Then we execute command git diff --cached. Now the local branch has three files and staging area has only one files. why it only show the change of c.txt not included the information that staging area dont has a.txt b.txt compared with local branch.

In a word, I have two question:
1. what happend when git commit, move or copy file from staging area to local branch?
2. what happend when git diff --cached? just compare files which staging area contains?

reference:

A commit is simply a checkpoint telling git to track all changes that have occurred up to this point using our last commit as a comparison. After committing, your Staging Area will be empty. from Git Gud: The Working Tree, Staging Area, and Local Repo

nail fei
  • 2,179
  • 3
  • 16
  • 36

3 Answers3

1

Many articles talk loosely about what the stage (or for that matter a commit) is / what it contains. Perhaps some of these authors don't know better, or perhaps they just think their explanation is more useful than a more accurate one. Whatever the reason, beware:

If someone tells you the index contains changes, they're misleading you.

The index contains a snapshot of the project. (Usually. During a conflicted merge it's a bit more complicated.) If someone says it "contains staged changes", you should understand that actually it contains a snapshot to which the staged changes have been applied (relative to the COMMIT object indicated by HEAD).

So after a commit, the stage is not empty. There are no staged changes, true, because anything that was staged just got committed (and HEAD moved to the new commit); but that means the index and HEAD contain matching snapshots.

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52
0

The staging area contains the changes that you have specified to be part of a commit but have not yet committed.

When you do git add, the changes are added to the staging until you actually run git commit. After you have staged a file for committing, you could make additional changes and those will appear in the Changes not staged for commit: part of git status. When you actually do run git commit, the changes that you had staged are used to make a new commit and the sha of this commit is made the new HEAD.

For your second question from the help docs of git diff:

git diff [--options] --cached [] [--] [...] This form is to view the changes you staged for the next commit relative to the named . Typically you would want comparison with the latest commit, so if you do not give , it defaults to HEAD. If HEAD does not exist (e.g. unborn branches) and is not given, it shows all staged changes. --staged is a synonym of --cached.

Adding the modifier allows you to see what changes you have staged to be committed.

When you do git reset --soft HEAD~, you are telling git to move the state of the repo to the commit previous to the one that the repo is currently pointing at but keep all of the changes to the files. So after running this command, your repo will have moved back on commit and doing git status will show as modified all the files that were in the commit that HEAD was at previously.

Schleis
  • 41,516
  • 7
  • 68
  • 87
0

Regarding git diff --cached

There is a discussion of using diff to compare the workspace, the index and the remote repo, here: https://stackoverflow.com/a/41249720/4522186

Randy Leberknight
  • 1,363
  • 9
  • 17