Git diff cached does nothing

Question

Here is where I'm at:

1. Created a new repo on GitHub
2. Initialized (git add .) my working directory locally on my PC
3. commited (git commit -m) all changes to stage
4. Made another change by adding a new .png file
5. Did another git commit -m
6. Now I want to see a list of all staged files that will be pushed before I actually push them for the first time (or really at any time) to the remote repo (https//.../../). So I assumed there'd be 2 commit full of changes to show for

If I tried to commit again (#3), it shows nothing to commit, working directory clean. So I must have committed successfully last time I assume is why it's saying this.

When I do a git status I get nothing to commit, working directory clean

BUT when I try to type git diff --cached --name-only or git diff --staged in terminal in OS X it did nothing. I just get the command prompt after running that command again.

Am I missing something here? I've searched for stuff on git diff but I must be blind.

Answer 1

Since an image is worth 1000 words, and I don't want to re-invent the wheel, allow me to link one of the illustrations of the https://git-scm.com book, showing the life-cycle of a file in git and showing the role of the cache. I admit there are a couple things I dislike about this picture but it will serve this purpose well.

If you've done some modifications and are in the middle of staging ("slang" for saying "adding to the cache") some of them with git add and the more granular git add -p, then the commands git diff and git diff --cached are ways to see what has already been added to the cache and what can still be added. By added here, I mean git add-wise, so adding an untracked file, or adding a modification.

• git diff: shows modifications that you can stage with git add. Note that this only applies to the "stage the file" arrow, it doesn't list untracked files.
• git diff --cached: shows only the diff between things already staged and the previous commit.

In your case, git diff --cached shows nothing, because you have already committed everything that was in your staging area, and have not added anything since then.

The reason the option is called --cached is because the git staging area was originally called the cache. You'll also encounter the term index.

@larsks's answer is correct, I just wanted to give this alternative picture in reaction to the comments which followed his answer.

Answer 2

Running git diff --cached will show you the difference between the repository and the index (the place where files are staged by git add before they are committed to the repository). It does not look at files in your working directory, nor does it compare differences between revisions in the repository.

If you want to see how your local repository differs from the upstream repository, first make sure your local cache of the remote repository is up-to-date:

git remote update

And then compare your local branch to the corresponding branch in the remote repository:

git diff --name-only mybranch origin/mybranch

..assuming that your remote is named origin, which it probably is.

Update

If you are pushing to an empty remote repository, then the answer to "what files will be pushed?" is "all of them", and there is nothing to run diff against.

You can run git ls-files to see a list of all files in the repository.

In my earlier example, mybranch would be the name of a branch, such as master or bug/1234 or this-is-a-nifty-feature, and the example assumes that you are pushing the local branch to a branch of the same name in the remote repository.

Update 2

You asked:

my remote branch is a url so what is origin...the uri/[repo name]? so origin is the uri? And what would I refer to as the name of my local branch?

A git repository can be associated with one or more remote repositories, called "remotes". If you clone a remote repository:

$ git clone git@github.com:larsks/sandbox.git

You will end up with a remote called origin referring to this repository:

$ cd sandbox
$ git remote -v
origin  git@github.com:larsks/sandbox.git (fetch)
origin  git@github.com:larsks/sandbox.git (push)

Your local branch is, initially, named master, so your initial push would look like:

$ git push origin master

This asks git to push your local master branch to the master branch of the remote repository referred to as origin.

But you can create new branches using the "git checkout -b" or "git branch" commands. There is a lot of documentation out there that will probably provide a better overview than I can in this answer. I would start with The Git Book.