Is there a way to review the changes a "git pull" would cause?

Question

I am new to git and a little leary of doing a "git pull". Is there a way to do something like a noop git pull? Something like ...

git pull --noop

... what would show what changes that would occur on my local disk?

Thanks

Say your branch's name is feature-log `git remote update && git log feature-log..origin/feature-log`. This will show what difference there is between the remote branch and local one. It is to run before `git pull` — smarber, Mar 17 '17 at 16:35
what does the `git remote update` do? Can I just run `git log feature-log..origin/feature-log`? — Red Cricket, Mar 17 '17 at 17:43
`git remote update` is like `git fetch` but defaults to updating all remotes. (I.e., it does *more than one* remote, if you have more than one remote. Unless you are doing something fancy, you have only one remote.) — torek, Mar 17 '17 at 20:46

score 1 · Answer 1 · answered Mar 17 '17 at 16:54

You can use git fetch. It's not true noop as it have some side effect at your local repo but it updates only remote tracking branches and does not affect your local branches. Then you can analyze changes in remote tracking branches and decide what to do with your local branches.

score 1 · Answer 2 · edited May 23 '17 at 12:02

I always advise people to avoid git pull. All git pull does is:

run git fetch for you, then
run another Git command for you.

But:

Sometimes it's important to inspect what the second command will do, and you can't do that if you run git pull.
Sometimes the second command goes wrong, and if you ran it yourself, you will have a much better idea what is going on.
The default for the second command is git merge, but git rebase is often a better choice. Even if git merge is correct, in some Git workflows, it may be important to swap the direction of the merge—i.e., merge your commit(s) into the upstream work, instead of merging the upstream work into your commit(s)—which you can't do with git pull.

Once you know all of this stuff cold, git pull may actually be more convenient, since you usually need to do something after git fetch and typing two commands is, like, so hard, y'know. :-) (And, git pull has a special corner case built in to it for pulling into an empty repository, but most people don't do that on purpose. That special case used to be broken: it could destroy work. It's fixed now, but that was yet another reason to avoid git pull entirely.)

Is there a way to review the changes a "git pull" would cause?

2 Answers2