git: 'log master..origin/master' not behaving as expected

Question

I'm trying to compare my copy of 'master' to that on the remote repository which it tracks. I thought that the following command would work, and often it seems to. However, sometimes it produces nothing and yet I know that the remote branch has many changes, which I can confirm by doing a pull.

git log master..origin/master

Can anyone explain this behavior and tell me what command I should be using to determine the changes between local and remote?

[Another piece of data: I've had it happen that 'git log master..origin/master' produces nothing. Then I do a pull. The pull fails because I have a working copy of some file. After this, 'git log master..origin/master' does show me the differences. It seems the pull has updated some local log? If so, how could I achieve this without doing (or attempting to do) a pull?]

Answer 1

pull is a fetch and a merge. Fetch downloads its logs from a remote server. I think this is what you are observing here.

http://www.kernel.org/pub/software/scm/git/docs/git-pull.html

Answer 2

It will only show you some differences if you did fetch something out of origin (to the local references of origin in your local repo).

That is why you see a difference after even a failed git pull:

• it first fetch
• then attempt to merge (and fail)

, but that is enough for the git log to extract the information you need, because they are on your local repo (after the fetch part)

Answer 3

This is because origin/master is a remote branch in your repository. It represents where origin's master branch was the last time you "looked" (fetched, which is part of pull and remote update).

When you pull, the fetch is performed, and origin/master gets updated. Then pull calls merge, which may or may not fail, but this has no effect on your remote branches.

You can also use git fetch --all or git fetch origin to get those updates.