How to see changed files after calling git fetch

Question

If two people are working on the same repository on github and the same branch master. Then say person A pushes their change to master and I as person B, how do I check the files changed in after calling git fetch?

If I do:

git fetch
git merge master origin/master

I get this line:

aa@DESKTOP-KQQ0A3T MINGW64 ~/..
$ git merge master origin/master
Merge made by the 'recursive' strategy.
 src/main.js | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

I like how the diff in src/main.js is described in that way, but that info appears only when I merge, so my question is, what command should I use to see the same info about the diff but before doing merge?

Answer 1

Before I answer at all, one quick note:

git merge master origin/master

Please don't do this: you want just git merge origin/master, not git merge master origin/master. (Fortunately you were on master when you ran this, so that Git ended up ignoring the master part. If it had not, you would have seen Merge made by the octopus strategy.)

---

Let's answer this part first:

I like how the diff in src/main.js is described in that way, but that info appears only when I merge, so my question is, what command should I use to see the same info about the diff but before doing merge?

To see what git merge would have said (assuming your work-tree is "clean" in that git status would say "nothing to commit"), run:

git diff --stat HEAD...HEAD@{upstream}

It's the --stat that produces the summary. Let's hold off a bit on the arguments to git diff here; but let's note (because it is important) that this assumes a simple, ordinary single-merge-base-commit merge, or a fast-forward operation (these are very likely).

how do I check the files changed in after calling git fetch?

This question itself reveals a bit of confusion (natural confusion, as Git is pretty confusing :-) ). Specifically, git fetch has not changed any files. What git fetch did was to obtain new commits. Each commit is a snapshot—a copy of all files as they were at the time you made the snapshot—and a snapshot is not, in itself, a change.

At the same time, though, if you look at a snapshot with git show or git log -p, Git will show a change. If a snapshot is a snapshot, not a changeset, how can Git show a change? Well, after a bit of thought, the answer is obvious. It's like one of those "spot the difference" pictures / quizzes:

• Look at the previous snapshot.
• Then look at this snapshot.
• What changed?

That's how git show shows you a change-set, even though the commit is a snapshot. The commit has a parent commit and Git just compares, with git diff, the parent hash~1 or hash^1, with the commit whose hash is hash. (The ~1 and ^1 suffixes both step back one first-parent in the Git graph.)

About git diff and its arguments

The git diff command is pretty complicated, so it can do more than just this, but to a first approximation, it simply compares two complete snapshots. It does not matter how you name them:

git diff origin/master master

for instance will find the commit—the hash ID—that origin/master names, and the commit that master names, and then compare the two. The output is a set of instructions: This is how to change the first commit to make it look like the second commit.

You can write:

git diff origin/master..master

if you prefer. When you do this sort of thing with git log, you will often see many commits, not just two. The git diff command is different: it just looks at those two commits. In effect, it throws away the .. part (except that they serve to separate the two names, of course).

When it comes to merging, there's another special git diff syntax: git diff A...B means git diff $(git merge-base A B) B. That's what we are using above. Normally, the three-dot syntax has a different meaning; git diff changes it to this particular "tell me what a merge would do" meaning, instead.

(This is not quite what git merge runs at the end after having done the merge, because after the merge completes, the merge base has changed. And, if the merge base is not just a single commit, the git diff A...B syntax will pick one single commit anyway, and compare those two commits, while git merge will default to a more complex strategy. Hence, after a true-merge finishes, Git can just run git diff --stat HEAD^ HEAD, which is essentially what it does. For a fast-forward not-really-a-merge "merge", Git can run git diff --stat HEAD@{1} HEAD.)

For more on the normal and special Git-diff-only meaning of the three-dot notation, see the gitrevisions documentation and the git diff documentation.