CODEWITHSUNDEEP
git
Scipion
Scipion

Reputation: 11888

git fetch origin doesnt tell me what files have been updated

When I use git fetch origin, I get that kind of message : 

remote: Counting objects: 7, done.
remote: Total 7 (delta 5), reused 5 (delta 5), pack-reused 2
Unpacking objects: 100% (7/7), done.
From http://xxx/xxx
   ee28fb0..fdca511  master     -> origin/master

However, it doesn't tell me what files exactly did change like an svn up would.

What do I need to use here ?

Upvotes: 1

Views: 90

Answers (2)

torek
torek

Reputation: 488203

You are starting with an incorrect premise, because git fetch deliberately does not update any files. This is on purpose: it allows you to git fetch at any time, since it never touches any of the files you may be working on. What git fetch does is add more commits to your repository, without affecting anything that is actually checked-out in the work area. (Git is rather Borg-like, if you are familiar with these villains from the Star Trek Next Generation series: you add the technological distinctiveness of the new commits to your git-borg collective. Most things you do with git just wind up adding new commits, with old commits persisting forever.)

The thing is that after you git fetch you would typically run either git merge or, usually more appropriate, git rebase. These commands will affect your work area files, and now is the time to ask what is going to change. (Git encourages different work-flow than svn, and git rebase is not exactly the same as svn up, but is probably what you would want here. If you never make any of your own changes, git merge --ff-only might be what you want here, but git rebase will achieve the same result.)

Because git allows and even encourages complex, distributed work-flows (where you and many other people all make many changes more or less simultaneously), viewing whose changes affect what can get complicated. If you never make any of your own changes, though, we get a much simpler situation, with an easy to use way to see what you have just obtained from elsewhere, and what git rebase or git merge --ff-only will do.

Most likely, what you want is a git diff --stat, as Mort answered. If you use git merge (with or without --ff-only), git runs a git diff --stat for you when it is done. This diff demands two revision IDs and compares the tree associated with the first revision to the tree associated with the second. The tricky part is choosing the revision IDs. Copying them from the output of git fetch works, but is annoying.

Here is a different way to achieve the same result without this kind of copying:

git diff --stat origin/master@{1} origin/master

(depending on your shell you may need to quote the curly braces).

The name origin/master@{1} tells git to fetch the value that was stored in origin/master before its most recent update. That will be the first hash git fetch showed, in this case ee28fb0....

The name origin/master tells git to fetch the current value, which is what git fetch just set it to: in this case, fdca511....

The nice thing about this is that you can go back further in time, by comparing origin/master@{2} to origin/master@{1} or to origin/master.

You can also compare master—your own branch—to any of these:

git diff origin/master@{1} master

This will show you what you changed in your master, as compared to whatever was in your origin/master just before you ran git fetch. (Add --stat to get the summarized version instead of the full diff.) Or: git diff master origin/master will show you what you have that is different from what you just obtained. If you never make your own changes, that's "what they did since then". If you do make your own changes, you will want to look instead at your and their merge base, which is where rebase and/or merge really come in, but which is another topic entirely.

Upvotes: 1

Mort
Mort

Reputation: 3549

Look at the output. You can run git diff --stat ee28fb0...fdca511 to get the files changed on master. (Or git log ee28fb0..fdca511, etc.)

The thing is, git fetch can update lots and lots of refs. So you do not always want to see all the updates in feature branches and QA branches when all you really care about is master.

Upvotes: 0

Related Questions